Releases

flagd core v0.15.5 fixes evaluation correctness bugs in fractional rollouts and JSONLogic and/or operators — teams relying on complex flag targeting rules should upgrade.

• securityDependency security alerts resolved

  Dependabot security alerts were resolved in this release. No CVEs are called out explicitly, but the dependency updates address known vulnerabilities in transitive deps. Upgrade if you're running flagd in a security-sensitive environment.

• breakingFractional evaluator fix: upgrade if you use targeting keys

  Null or missing targeting keys in fractional evaluators previously caused undefined behavior. If your flag rules use fractional/percentage rollouts and some users may lack a targeting key (e.g. anonymous users), upgrade to avoid incorrect bucket assignments.

• breakingJSONLogic and/or bug fix may change evaluation results

  The jsonlogic and/or operator bug could cause flag rules with compound boolean logic to evaluate incorrectly. Review any rules relying on and/or conditions after upgrading — results may change from what you saw in v0.15.4.

v3.3.9 is a focused patch addressing four bugs — including a panic in ApplicationSet DuckType Generator and a UI crash in pod logs — plus a Go version bump to resolve CVEs.

• securityUpgrade to patch Go-level CVEs

  The Go runtime was bumped specifically to resolve CVEs. The release notes don't enumerate the exact CVE IDs, but if you're running 3.3.x in production, upgrade to 3.3.9 now rather than waiting for your next maintenance window. All container images are cosign-signed and SLSA Level 3 provenance is available — verify signatures before deploying if your pipeline requires it.

• breakingApplicationSet DuckType Generator panic is now fixed — review affected ApplicationSets

  If you use DuckType Generators and have clusters with non-string label values, previous versions would silently panic. After upgrading, those ApplicationSets will now process correctly rather than crashing. Do a quick audit of your ApplicationSet resources post-upgrade to confirm they're reconciling as expected — you may see previously-failing sets suddenly become active.

• enhancementOCI metadata caching restored — expect reduced registry pressure

  The Redis cache for OCI metadata was broken, meaning every OCI source lookup was hitting the registry directly. With this fix, caching works again. If you use OCI-sourced ApplicationSets or Helm charts, you should see reduced latency and fewer registry requests after upgrading. No configuration change needed.

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.

Vitess v24 ships structured JSON logging by default, window function pushdown for sharded keyspaces, OpenTelemetry tracing, and a security fix for backup manifest command injection. 460 PRs merged.

• securityBackup MANIFEST command injection is now blocked by default

  Prior to v24, an attacker with write access to backup storage could modify the MANIFEST file to inject arbitrary shell commands that VTTablet would execute during restore. This is now blocked — the MANIFEST decompressor field is ignored unless you explicitly pass --external-decompressor-use-manifest. If you're on v23 or earlier, treat backup storage access controls as a security boundary and audit who can write to it.

• breakingAudit backup restore configs for MANIFEST decompressor

  If your VTTablet restore process relied on the decompressor command stored in backup MANIFESTs (i.e., you never set --external-decompressor but backups still decompressed), restores will silently skip decompression in v24 and likely fail. Add --external-decompressor-use-manifest to your VTTablet config to preserve old behavior, but read the security advisory first: a compromised backup store could execute arbitrary commands on your tablet. Evaluate whether you actually need this or can pass --external-decompressor explicitly instead.

• breakingRemove deprecated VTOrc API endpoint and metric references

  The /api/replication-analysis endpoint returns 404 in v24 — any monitoring scripts, Grafana dashboards, or alerting rules hitting that URL will break silently or with errors. Switch to /api/detection-analysis (same params, same response format). Also replace DiscoverInstanceTimings with DiscoveryInstanceTimings in dashboards. Do this before deploying v24 to production.

• enhancementMigrate tracing to OpenTelemetry now, not in v25

  opentracing-jaeger and opentracing-datadog are deprecated in v24 and will be removed in v25. The migration is straightforward: replace --tracer opentracing-jaeger with --tracer opentelemetry, and swap --jaeger-agent-host host:port for --otel-endpoint host:4317. Jaeger v1.35+ accepts OTLP on port 4317 by default. Datadog users should point to the Agent's OTLP ingestion endpoint. Do this upgrade cycle, not the next one.

• enhancementAdd --cell flag to VTOrc now

  --cell is optional in v24 but becomes required in v25. Multi-cell deployments especially should add it now — startup validation against the topology will catch misconfiguration early, and it unblocks future cross-cell recovery logic in VTOrc. One flag, no downtime, avoids a forced change next release.

Karmada v1.17.2 is a patch release fixing scheduler misrouting bugs, operator reconciliation failures, and a Job replica assignment error — plus an Alpine base image bump for security.

• securityRebuild or pull updated images to get the Alpine 3.23.4 base

  The base image was bumped from Alpine 3.23.3 to 3.23.4. If you're running air-gapped or mirrored image setups, make sure to pull and mirror the new v1.17.2 images. Check Alpine's changelog for the specific CVEs addressed if your compliance process requires it.

• breakingScheduler backoffQ misrouting may have masked real scheduling failures

  Bindings with insufficient cluster replicas were incorrectly queued in backoffQ instead of unschedulableBindings. This means your scheduler may have been retrying workloads on an exponential backoff schedule rather than surfacing them as unschedulable. After upgrading, expect some previously silent failures to become visible in unschedulableBindings — review any workloads that seemed stuck or slow to schedule.

• enhancementUpgrade if you use karmada-operator with custom tolerations/affinity or multi-cluster Jobs

  Two high-impact fixes landed here: operator-managed deployments were silently ignoring tolerations and affinity configs, which could cause pods to land on unintended nodes. And Job completion counts were being assigned incorrectly across clusters, which could corrupt Job semantics in distributed workloads. Both are straightforward regressions worth patching immediately if either feature is in use.

Karmada v1.16.5 is a focused patch release fixing scheduler queue misrouting, Job replica assignment errors, and operator reconciliation failures, plus an Alpine base image bump.

• securityAlpine 3.23.4 base image — rebuild and redeploy your Karmada components

  The Alpine bump from 3.23.3 to 3.23.4 addresses upstream security concerns. If you're running custom-built Karmada images or have image scanning in your pipeline, update your base images accordingly. The official images in this release already include the updated base.

• breakingScheduler queue misrouting causes stalled workloads — patch immediately

  The backoffQ vs unschedulableBindings misrouting bug means workloads with insufficient cluster replicas may have been stuck in the wrong queue, causing unexpected scheduling delays or failures. If you've seen bindings that appear perpetually pending despite enough cluster capacity becoming available, this fix directly addresses that. Upgrade to v1.16.5 and check for any bindings that are stuck — they should reschedule automatically after the upgrade.

• breakingJob completions were assigned to wrong clusters — review existing Job distributions

  The Job completion replica assignment bug could have led to incorrect work distribution across member clusters. Jobs that ran on this version may have had skewed completion counts per cluster. After upgrading, inspect any multi-cluster Jobs that were scheduled on v1.16.4 to verify their completion semantics were not affected in production.

Karmada v1.15.8 is a targeted bug-fix patch addressing scheduler queue misrouting, missing cluster info in events, and an operator reconciliation failure. Alpine base image bumped for security.

• securityRebuild and redeploy to pick up alpine:3.23.4 patches

  The alpine base image bump from 3.23.3 to 3.23.4 addresses unspecified security concerns. If you're running custom Karmada images built from the upstream base, rebuild against the new base. If you're using official images, pulling v1.15.8 is sufficient.

• breakingScheduler queue misrouting can cause workloads to be stuck — patch immediately

  The backoffQ bug is particularly dangerous in production: when a binding hits insufficient replicas, it gets retried with exponential backoff instead of being placed in unschedulableBindings where it belongs. This means your workloads silently wait longer than expected before rescheduling. If you're running ClusterAffinities with replica constraints, upgrade to v1.15.8 — don't wait on this one.

• enhancementOperator idempotency fix prevents init reconciliation crashes on restarts

  The non-idempotent secret creation in karmada-operator meant that if the operator restarted mid-initialization, reconciliation would fail. This is now fixed with an idempotent approach. If you've been seeing operator init failures after pod restarts or rolling updates, this patch resolves the root cause.

containerd API v1.11.0 ships a new shim bootstrap protocol, container filesystem copy transfer types, and sandbox spec field support — aligning with the containerd 2.3 runtime release.

• securitygRPC updated from v1.59.0 to v1.79.3 — multiple CVE fixes included

  A 20-minor-version jump in gRPC covers a significant span of security and stability fixes. If your environment pins or vendors gRPC separately, reconcile your dependency tree against v1.79.3. The golang.org/x/* packages also moved forward across the board, so a full dependency audit is warranted before deploying this API version in production.

• breakingSandbox API: Container field removed, update any sandbox metadata consumers

  The Container field has been dropped from sandbox metadata and replaced with a spec field. If you have tooling, controllers, or custom runtimes that read or write sandbox metadata directly, audit them now. This is an API-level change — anything compiled against the old proto definitions will break at runtime when targeting containerd 2.3.

• breakingShim bootstrap protocol is now protobuf — custom shim implementations need updating

  The new shim bootstrap protocol switches from JSON to protobuf and uses enums instead of strings for capabilities and log levels. If you maintain a custom shim or vendor the containerd API, you must update your bootstrap handling before deploying containerd 2.3. Third-party shims (e.g., kata-containers, nydus) likely need corresponding releases — check their compatibility before upgrading.

KServe v0.18.0 is a large release dominated by LLMInferenceService (llmisvc) maturation, two CVE fixes, and multi-node inference groundwork—teams running LLM workloads should review carefully before upgrading.

• securityApply immediately: three CVE fixes in this release

  CVE-2026-32597 (PyJWT critical header bypass), CVE-2026-33186 (gRPC authorization bypass), and CVE-2026-30922 (pyasn1 DoS) are all patched here. If you're running KServe with gRPC inference endpoints or Python-based runtimes exposed externally, these are not optional. Upgrade to v0.18.0 or apply the patches to your current version. The gRPC bypass in particular could allow unauthenticated requests to reach protected inference endpoints.

• breakingPYTHONPATH is now blocked in webhooks—audit your ServingRuntimes

  A new webhook validation blocks PYTHONPATH from being set in InferenceService or ServingRuntime specs. If any of your custom ServingRuntimes or ISVCs set PYTHONPATH (a common pattern for custom Python module paths), they will be rejected at admission after this upgrade. Audit all your ServingRuntime and ISVC manifests before upgrading and remove or replace PYTHONPATH usage.

• breakingHelm chart renamed to 'kserve-resources'—update your Helm releases

  The KServe Helm chart name changed from 'kserve' to 'kserve-resources'. If you manage KServe via Helm, a naive upgrade will not find the old release name. Plan a migration: either rename the existing Helm release or uninstall/reinstall. CI pipelines, GitOps configs, and any tooling referencing the chart name need updating before you run the upgrade.

• enhancementLLMInferenceService autoscaling is production-ready—evaluate for LLM workloads

  v0.18.0 ships KEDA/HPA and WVA-based autoscaling for LLMInferenceService, plus LWS as an autoscaling target for multi-node workloads. If you're running vLLM-backed inference at scale and hitting manual scaling pain, now is a good time to test llmisvc autoscaling in staging. The WVA dependency was bumped to v0.6.0-rc3, so treat it as near-stable but not fully GA.

Kyverno 1.18 hardens HTTP context security with blocklist enforcement and scoped tokens, fixes multiple image verification bugs including a silent bypass, and expands CLI policy testing coverage.

• securityAudit HTTP context policies before upgrading — blocklist is now enforced

  Any policy using HTTP context loading will now be subject to a configurable blocklist. Calls that previously succeeded might be blocked after upgrade. Before rolling out 1.18, inventory all policies with HTTP context entries, verify their target URLs are not on the default blocklist, and configure FLAG_HTTP_BLOCKLIST overrides where needed. Also check that scoped token authorization doesn't break policies relying on broader token access. Test in a non-production cluster first.

• securityImage verification silent bypass is patched — verify your policies are actually enforcing

  A bug in processResourceWithPatches caused it to return nil on patch failure, which silently skipped image verification. If you've been running image verification policies and assumed they were enforcing, run a retroactive compliance scan after upgrading to confirm enforcement was working as expected. Also check the CVE fixes: CVE-2026-32280 (intermediate cert limiting) and CVE-2026-32283 (Go toolchain upgrade) are included in this release and warrant upgrading promptly.

• enhancementUse successEventActions to reduce event spam in large clusters

  High-traffic clusters with broad Kyverno policies generate enormous volumes of success events, which can overwhelm etcd and make event streams useless. The new successEventActions ConfigMap parameter lets you filter exactly which success events get emitted. Add this to your Kyverno ConfigMap after upgrading and tune it based on which policy actions actually need visibility. Pairs well with the existing omitEvents setting — watch out for the new warning if you configure conflicting values.

Microcks 1.14.0 adds Kafka request-reply for async mocking and expands Callback/Sync-to-Async support across REST, gRPC, and the UI. A bug fix prevents HTTP method mutation on mocked operations.

• securityRebuild custom images on updated UBI9 base

  The base image bumps to UBI9 9.7-1776833838. If you build custom Microcks images on top of the official one, rebuild and re-test after upgrading to pick up the upstream OS patches included in this UBI update.

• breakingVerify REST mock routing after operation method fix

  The fix for issue #2028 prevents the operation HTTP method from being overridden — a subtle bug that could cause mocks to respond incorrectly if the method was being mutated. Verify any existing REST mocks that rely on method-specific routing to confirm they behave as expected after upgrade.

• enhancementAdopt Kafka request-reply for async testing

  Kafka async mocks now support request-reply semantics. If your team uses Microcks to mock event-driven services over Kafka, this unlocks proper two-way interaction testing without external tooling. Review the updated API for Callback and Sync-to-Async support alongside the new triggers UI before migrating existing Kafka mock setups.

SPIRE v1.14.6 patches two critical security vulnerabilities in node attestation: an EC2 instance impersonation flaw and a race condition in join token validation.

• securityUpgrade immediately if using aws_iid node attestation

  The aws_iid bug is severe: any EC2 instance under attacker control could forge the identity of any other EC2 instance during attestation, bypassing all downstream SPIFFE ID assignment and workload authorization. If you use aws_iid attestation in any environment, treat this as a critical breach risk and upgrade to v1.14.6 now. After upgrading, audit your node attestation logs for anomalous registrations — specifically instances claiming identities inconsistent with their actual AWS metadata.

• securityJoin token race condition allows double-registration — patch now

  The TOCTOU flaw means two concurrent requests with the same join token could both complete attestation successfully, resulting in two agents registered under one token. If join tokens are distributed in automated pipelines or ephemeral environments, an attacker who intercepts a token could race a legitimate agent to claim it. Upgrade to v1.14.6, then review your join token issuance and revocation policies. Consider switching to shorter-lived tokens or alternative attestation methods like x509pop for sensitive workloads.

v1.13.6 patches two serious security vulnerabilities in SPIRE: an EC2 instance impersonation flaw in the AWS IID attestor and a race condition in join token handling. Upgrade immediately.

• securityUpgrade now if you use AWS IID node attestation

  The AWS IID attestor vulnerability is severe: any attacker controlling an EC2 instance could forge the identity of any other EC2 instance in your environment during node attestation. All downstream RBAC, SVID issuance, and workload identity decisions would operate on the forged identity. If you run SPIRE with the aws_iid server plugin, treat this as a critical incident — patch to v1.13.6 before doing anything else. Review your SPIRE server logs for unexpected node attestation events from EC2 instances, especially cross-account or cross-region patterns.

• securityAudit join token usage if you allow concurrent agent bootstrapping

  The TOCTOU bug in join token handling means two agents racing to attest with the same token could both succeed — violating the one-time-use guarantee. In practice this could allow unauthorized agents to join your trust domain. After upgrading, rotate any join tokens that may have been used during periods of concurrent agent bootstrapping. If you use join tokens in automation (e.g., init containers, CI pipelines), review whether parallel execution could have triggered this race.

NATS v2.12.8 is a substantial bug-fix release targeting JetStream stability — particularly clustered stream/consumer reliability, Raft edge cases, and a bearer JWT disclosure vulnerability in the monitoring API.

• securityPatch immediately: /connz was leaking bearer JWTs

  Any deployment using JWT-based auth with the monitoring endpoint exposed (even internally) was potentially leaking bearer tokens in /connz responses. Rotate any JWTs that may have been exposed, audit monitoring endpoint access logs, and upgrade to v2.12.8 now. If you can't upgrade immediately, restrict /connz access via firewall or NATS monitoring auth.

• securityCLI argument secrets now redacted in monitoring

  Route and cluster URLs passed as CLI arguments (which often contain credentials) were previously visible in monitoring output. Upgrade to v2.12.8 and review any monitoring dashboards or log aggregation pipelines that may have captured this data historically.

• enhancementJetStream cluster operators: test your scaling and recovery paths

  This release fixes several nasty edge cases — stream leader catch-up from snapshots, Raft commit index resets on term mismatches, in-flight assignment visibility for stream/consumer info, and the 'last sequence mismatch' error from failed proposals. If you've been seeing any of these intermittent errors in clustered JetStream, v2.12.8 is a high-priority upgrade. After upgrading, monitor for reduced error rates in stream info and consumer info endpoints during scaling operations.

NATS v2.11.17 is a security and stability patch addressing JWT bearer token exposure in monitoring endpoints, credential redaction gaps, and several crash/correctness bugs.

• securityPatch immediately: /connz was leaking bearer JWTs

  Any operator exposing the NATS monitoring port (default 8222) to internal or external networks should treat this as urgent. Bearer tokens visible in /connz could be harvested and replayed. Rotate any JWTs that may have been exposed, audit who had access to your monitoring endpoints, and upgrade to 2.11.17 now. If you cannot upgrade immediately, firewall the monitoring port.

• securityCLI-embedded secrets were visible in monitoring output

  If your NATS deployment passes route or cluster URLs with embedded credentials as command-line arguments, those secrets were previously visible in monitoring output. Audit your monitoring data for any historical exposure, rotate affected credentials, and upgrade. Long-term, prefer config files or environment-based secret injection over CLI arguments.

• breakingRepeated CONNECT behavior change may affect edge-case clients

  The fix for repeated CONNECT messages clearing subscriptions changes previously tolerated (but incorrect) behavior. Custom clients or unusual connection patterns that send multiple CONNECT messages on the same connection could see subscriptions unexpectedly dropped. Audit any non-standard client code before upgrading in production.

Prometheus v3.11.3 patches three security vulnerabilities: a credential leak, a DoS vector via malformed snappy payloads, and a stored XSS in the classic UI.

• securityRotate AzureAD client secrets if /-/config was accessible

  If you use AzureAD remote write and the /-/config endpoint was reachable by anyone other than trusted admins, treat your client_secret as compromised. Rotate it in Azure AD immediately, then upgrade to v3.11.3. Also audit who has access to that endpoint — it should never be public-facing.

• securityUpgrade immediately if remote-read is enabled and exposed

  The snappy decode vulnerability lets an attacker send a crafted request with an inflated declared length, potentially exhausting memory. If your Prometheus remote-read endpoint is reachable from outside your trust boundary, this is a real DoS risk. Upgrade to v3.11.3 as soon as possible — there's no config-level workaround short of disabling remote-read entirely.

• securityAssess XSS exposure if you still run the classic UI

  The stored XSS in the old UI heatmap affects any deployment where users can influence label values (e.g., via instrumented applications) and other users view those charts. If you've already migrated to the new UI, you're not affected. If you haven't, upgrade now — or at minimum restrict UI access to trusted users until you do.

v1.15.0 brings latency improvements for complex authorization models via edge pruning, fixes a cache bug in the experimental weighted graph checker, and patches Go stdlib CVEs by upgrading to Go 1.26.2.

• securityUpdate immediately to patch Go stdlib vulnerabilities

  This release ships Go 1.26.2, which addresses vulnerabilities in the Go standard library. If you run OpenFGA as a managed binary or container, pull the new image now. If you build from source, ensure your toolchain matches. Don't wait on this — stdlib vulns can affect TLS, HTTP parsing, and crypto paths that OpenFGA relies on.

• enhancementRe-benchmark list objects performance on complex models

  Edge pruning in the list objects pipeline cuts unnecessary graph traversal. If your authorization model has deep or wide relationship graphs, you should see reduced p99 latency on ListObjects calls. Run your existing load tests against v1.15.0 and compare — this is a free win that requires no config changes.

• enhancementRe-evaluate weighted_graph_check cache behavior if you hit cold-start issues

  The experimental weighted_graph_check feature was silently skipping its cache on cold start or when the cache controller was disabled, which could explain unexpected latency spikes early in pod lifecycle. The fix aligns behavior with the documented contract: zero invalidation time means use the cache. If you're using this experimental feature, test it again — behavior will differ from what you may have measured before.

Prometheus v3.5.3 is a security-only release patching four vulnerabilities: credential exposure, two snappy decompression bombs, and a stored XSS in the legacy UI.

• securityRotate AzureAD client_secret immediately if /-/config was exposed

  Any Prometheus instance using AzureAD remote write had its OAuth client_secret visible in plaintext at the /-/config endpoint. If that endpoint was reachable by untrusted users or scraped by monitoring tools, treat the secret as compromised. Rotate it in Azure AD, update your Prometheus config, and then upgrade to v3.5.3. After upgrading, restrict /-/config access via --web.enable-admin-api controls or a reverse proxy allowlist.

• securityUpgrade now if you accept remote-read or remote-write from untrusted sources

  Both remote-read and remote-write endpoints were vulnerable to decompression bomb attacks — a crafted snappy request with an inflated declared size could exhaust memory. If your Prometheus is internet-facing or accepts data from multiple tenants, this is a denial-of-service risk. Upgrade to v3.5.3 immediately. There is no config-level workaround; the fix is in the code.

• securityPatch stored XSS if anyone uses the legacy UI with untrusted label values

  The old UI heatmap rendered 'le' label values without escaping, allowing stored XSS. If your users browse the legacy UI and your metrics include 'le' labels sourced from external or user-controlled systems, malicious JavaScript could execute in their browsers. Upgrade to v3.5.3. As a short-term measure, direct users to the new UI instead.

A large security maintenance release for the LTS channel: kernel jumps from 6.6.107 to 6.6.127 and closes hundreds of CVEs accumulated since the last LTS point release, plus a ca-certificates update and a local dev fix for arm64 Macs.

• securityApply the kernel update promptly — large CVE backlog closed

  This release rolls up roughly 20 kernel point releases (6.6.107 through 6.6.127), closing several hundred CVEs accumulated over that span. Treat this as a mandatory patch cycle rather than a routine bump — teams on 4081.3.6 or earlier have been running with months of unpatched kernel CVEs, some of which affect networking, filesystems, and memory management subsystems commonly hit in container workloads. Roll this out to fleets on the LTS channel as soon as your update ring allows.

• enhancementVerify TLS trust chains after ca-certificates 3.116→3.122 jump

  ca-certificates jumped from 3.116 to 3.122, spanning multiple NSS releases. If you pin or vendor CA bundles separately from the OS image, check for any removed or distrusted root certificates in that range that could break TLS validation for internal services or older endpoints.

• enhancementFaster local VM testing on Apple Silicon

  The QEMU launcher script now enables HVF acceleration on arm64 Macs (Flatcar#1901). If you develop or test Flatcar images locally on Apple Silicon, update your local scripts/tooling to pick this up — VM boot and test cycles should be noticeably faster.

Flatcar stable-4593.2.0 is a large security + infrastructure release: 150+ kernel CVEs patched, openssh/openssl/curl/intel-microcode updated, and significant initrd/partition layout changes that need attention before upgrading.

• securityMass CVE remediation across kernel and userspace — update now

  Linux kernel patches cover 150+ CVEs, and userspace components (openssh 10.2_p1, openssl 3.5.4, curl 8.16.0, intel-microcode, gnupg, pam) each carry their own CVE fixes. This is a large security catch-up from Stable 4459.2.4. Any Flatcar node on stable should be updated promptly — the auto-update mechanism will handle it, but verify nodes are actually cycling through updates if you have update pauses configured.

• breakingsshd now uses OpenSSH upstream defaults including post-quantum key exchange

  sshd_config no longer hard-codes Ciphers, MACs, and KexAlgorithms; OpenSSH upstream defaults now apply, which includes post-quantum key exchange. If your environment requires specific legacy algorithms (e.g., for compliance tooling or older SSH clients), add drop-in config to /etc/ssh/sshd_config.d/ before upgrading. Test SSH connectivity after the update in a non-prod node first.

• breakingPartition layout changed; kernel module availability in first-stage initrd is reduced

  Partition sizes have grown: /boot to 1 GB, /usr to 2 GB, /oem to 1 GB. Existing nodes can still update, but new disk images will use the larger layout. If you have tight disk quotas, pre-provision or verify disk images have room. Also, the kernel+initrd on /boot is now half the size due to a two-stage initrd split — if any required drivers were only in the first-stage initrd, you may see boot issues. Report regressions to the Flatcar team immediately.

Patch release upgrading to Wasmtime 44 and fixing a pooling allocator crash, plus new glibc builds for GPU workloads on Linux.

• securityUpgrade if you hit pooling allocator crashes — the fix prevents silent failures

  The pooling allocator was being enabled without checking whether the host hardware actually supports it, which could cause runtime crashes or unpredictable memory behavior. If you've seen wash-runtime instability on certain host types, this fix directly addresses that. Upgrade and monitor memory allocation behavior post-deploy.

• breakingTest Wasmtime 44 upgrade in staging before rolling to production

  Wasmtime 44 is a major version bump for the underlying runtime. While wasmCloud wraps it, Wasmtime releases frequently carry behavior changes in memory handling, WASI interfaces, or component model semantics. Validate your component workloads in a non-production environment before upgrading clusters.

• enhancementGPU workloads on Linux now have proper glibc builds — start testing if relevant

  If you're running or planning wasmCloud workloads that touch GPU features on Linux, the new glibc builds resolve compatibility issues with standard Linux distributions that expect dynamically linked runtimes. Pull the new artifacts and validate against your target GPU host environment.

Maintenance-heavy edge release with OpenSSL/rustls security bumps, a policy admission fix for Gateway routes, and a more robust annotation-to-metric-label conversion in the injector.

• securityPick up OpenSSL and rustls-webpki patches now

  Two OpenSSL crate bumps landed in this release, plus a rustls-webpki update. These sit in the proxy's TLS stack. If you're running any Linkerd edge build in a security-sensitive environment, upgrade to edge-26.4.4 to get the patched cryptographic dependencies rather than waiting for the next stable.

• breakingVerify Gateway route policies after the admission webhook fix

  The admission webhook previously ran full validation on Gateway routes even when they contained fields Linkerd doesn't support, causing legitimate routes to be rejected. That's fixed now — but if you worked around this by restructuring routes, review whether those workarounds are still needed or are now masking misconfigurations.

• enhancementTest chart override behavior if you use custom install values

  The fix to apply overrides to chart values on install closes a gap where certain Helm value overrides weren't being applied. If you have installation automation that relies on specific override patterns, run a dry-run install against this version to confirm the resulting values match expectations before rolling to production.

Envoy v1.38 is a massive release with several breaking changes requiring immediate action — RSA key usage enforcement, BoringSSL build flag changes, and tcp_proxy config validation are the top priorities before upgrading.

• securityPatch CVE-2026-27135 by upgrading to v1.38

  This release includes the nghttp2 patch for CVE-2026-27135, which affects HTTP/2 header field handling. If you're running Envoy as an HTTP/2 gateway or proxy, this is a direct exposure. Prioritize upgrading clusters that terminate or proxy HTTP/2 traffic. RBAC header matcher also received a fix preventing concatenation-based bypass attacks — another reason to treat this upgrade as security-relevant.

• breakingAudit TLS configs before upgrading — RSA key usage now enforced

  enforce_rsa_key_usage defaults to true starting this release and will be removed entirely next release, making it permanent. Any upstream TLS connection where the certificate's key usage doesn't match the negotiated cipher will be rejected. Before upgrading, audit your upstream certificate configurations. Test in staging first — silent failures in prod will be connection resets, not helpful error messages.

• breakingUpdate BoringSSL FIPS build pipelines before building v1.38

  The --define=boringssl=fips Bazel flag is gone. CI/CD pipelines or Dockerfiles that build Envoy with FIPS mode will fail silently or error out. Replace with --config=boringssl-fips. If you're consuming official binaries rather than building from source, this doesn't affect you directly, but verify your supply-chain tooling if you maintain custom builds.

• enhancementOpenTelemetry metrics over HTTP — drop the collector sidecar

  The OTel stat sink can now push metrics directly via OTLP/HTTP without requiring a collector sidecar. If you're running otel-collector as a DaemonSet purely for Envoy metrics forwarding, you can simplify that architecture. Evaluate whether direct OTLP/HTTP export to your backend (Grafana Cloud, Honeycomb, etc.) reduces operational overhead in your environment.

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.

CoreDNS v1.14.3 ships full TSIG verification across all transports, multiple Go security CVE fixes, cache prefetch improvements, and a new forward plugin max_age option — a solid operational hardening release.

• securityUpgrade immediately for 13 Go CVE fixes and TSIG transport hardening

  Go 1.26.2 in this build addresses 13 CVEs. Beyond the runtime fixes, TSIG verification gaps in DoH, DoH3, QUIC, and gRPC transports are now closed — if you run any of those transports with TSIG, unauthenticated requests could previously slip through. Upgrade to v1.14.3 and verify your TSIG configurations are still valid after the stricter enforcement.

• breakingDoH oversized GET requests are now rejected — validate your clients

  CoreDNS now rejects oversized dns query parameters in DoH GET requests. Any client sending unusually large DNS-over-HTTPS GET queries will start getting errors. Test your DoH clients against this build in staging before rolling out; most well-behaved clients are unaffected, but custom or non-standard DoH implementations should be checked.

• enhancementUse max_age in the forward plugin to prevent stale upstream connections

  Long-lived upstream connections can silently degrade or get dropped by middleboxes. The new max_age option in the forward plugin lets you set an absolute connection lifetime. If you've seen sporadic upstream timeouts or resolution failures that resolve themselves, configure max_age to force periodic reconnection — start with something like 30s–5m depending on your upstream stability.

Pure security patch: Go runtime bumped to 1.23.9 and vulnerable dependencies updated. No functional changes — upgrade is the only action needed.

• securityUpgrade to v1.19.5 immediately — this is a pure CVE fix

  The cert-manager team explicitly recommends all users upgrade. The changes are limited to Go runtime and dependency bumps, so there is no functional risk in upgrading. If you are on any v1.19.x release, this is a straight swap with no migration steps. Check your deployment method (Helm, static manifests, OperatorHub) and roll it out to all clusters. Delaying leaves your cert-manager pods running with known vulnerable Go packages.

v1.33.4 is a security-critical patch fixing a Lua code injection CVE in Contour's Cookie Rewriting feature — upgrade immediately, and note the hard Envoy 1.35.0 minimum requirement.

• securityPatch CVE-2026-41246 immediately — arbitrary code execution risk in shared Envoy

  Any tenant with RBAC permissions to create or modify HTTPProxy resources could inject arbitrary Lua code through a crafted pathRewrite value. In multi-tenant clusters where Envoy is shared infrastructure, this means a compromised or malicious tenant could steal xDS client credentials or deny service to other tenants. Upgrade Contour to v1.33.4 and ensure Envoy is at 1.35.0 or later before deploying. Audit your RBAC policies to limit HTTPProxy write access to trusted principals as a defense-in-depth measure.

• breakingEnvoy 1.35.0 minimum — verify your Envoy version before upgrading Contour

  This release will not function correctly with Envoy versions older than 1.35.0 due to the new filterContext-based Lua approach. If you manage your own Envoy image or pin versions, upgrade Envoy first. The bundled Envoy in the official manifests is already at v1.35.10, so if you use the standard deployment you're covered — but custom or air-gapped environments need explicit attention here.

• enhancementReview HTTPProxy RBAC regardless of upgrade timing

  Even after patching, the underlying attack surface is broad write access to HTTPProxy resources. Take this as a signal to tighten RBAC: restrict HTTPProxy creation/modification to platform operators rather than application developers where possible. In high-trust multi-tenant environments this kind of privilege separation is the right long-term control.

v1.32.5 is a security patch fixing a Lua code injection vulnerability (CVE-2026-41246) in Contour's Cookie Rewriting feature, plus an Envoy bump to v1.34.14. Upgrade immediately in multi-tenant environments.

• securityPatch CVE-2026-41246 immediately in multi-tenant clusters

  Any cluster where untrusted users or teams have RBAC permissions to create or modify HTTPProxy resources is directly exposed. An attacker crafts a pathRewrite.value that breaks out of the Lua string context, gaining code execution in Envoy — which runs as shared infrastructure. That means credential theft (xDS client certs) or denial of service for every tenant on the same Envoy instance. Upgrade to v1.32.5 now. While you prepare the upgrade, audit who has create/update rights on HTTPProxy and tighten RBAC to the minimum necessary.

• breakingReview existing cookieRewritePolicies after upgrade

  The fix adds escaping to pathRewrite.value inputs. Legitimate values with special characters (backslashes, quotes, etc.) will now be escaped before Lua interpolation, which changes runtime behavior. Test any HTTPProxy resources using cookieRewritePolicies[].pathRewrite.value in a staging environment post-upgrade to confirm cookie rewriting still behaves as expected.

• enhancementEnvoy v1.34.14 is bundled — no separate action needed

  The Envoy bump is included in the Contour image. If you run a managed Envoy deployment alongside Contour, verify your Envoy image is also updated to v1.34.14 to stay consistent with Contour's tested configuration.

Contour v1.31.6 patches a Lua code injection vulnerability (CVE-2026-41246) in Cookie Rewriting that could allow arbitrary code execution in shared Envoy infrastructure.

• securityPatch immediately if you allow untrusted users to create/modify HTTPProxy resources

  CVE-2026-41246 is a privilege escalation path in multi-tenant clusters. Any user with RBAC write access to HTTPProxy objects can inject arbitrary Lua into Envoy — and since Envoy is shared infrastructure, the blast radius extends to other tenants and exposes xDS credentials. Upgrade to v1.31.6 now. If you cannot upgrade immediately, audit existing HTTPProxy objects for suspicious pathRewrite values and tighten RBAC so only trusted principals can write HTTPProxy resources.

• enhancementReview RBAC around HTTPProxy write permissions regardless of upgrade status

  This CVE class — user-controlled values interpolated into code — is a design risk whenever untrusted users can write Kubernetes custom resources that drive proxy configuration. Use this as a prompt to apply least-privilege RBAC on HTTPProxy, HTTPRoute, and similar resources across your clusters. Namespace-scoped RBAC and admission webhooks that validate pathRewrite values are good mitigations to layer on top of the patch.

Crossplane v2.2.1 patches two user-reported bugs — ImageConfig prefix rewrite dependency upgrades and ResourceSelector handling — plus a broad sweep of security dependency updates.

• securityUpgrade to v2.2.1 immediately for dependency security fixes

  This release pulls in security patches for at least 8 upstream libraries including cosign, go-git, go-jose, and cloudflare/circl. These are not cosmetic bumps — go-git had two separate security-tagged updates in this release alone (v5.17.1 and v5.18.0). If you're running v2.2.0, plan the upgrade now. The patch is a drop-in replacement with no breaking changes.

• breakingVerify your ImageConfig prefix rewrite setups after upgrading

  If you use ImageConfig prefix rewrites to redirect package pulls (e.g., to a private registry mirror), your packages may have been silently stuck on stale dependency versions before this fix. After upgrading to v2.2.1, expect Crossplane to reconcile and potentially upgrade dependent packages that were previously frozen. Review installed package versions post-upgrade to confirm the expected state.

• enhancementComposition functions can now use broad ResourceSelectors safely

  Composition functions that need to select all existing resources of a given kind no longer need workarounds. A ResourceSelector with only apiVersion and kind set is now valid. If you patched around this limitation with explicit matchLabels or matchName wildcards, you can simplify those selectors in your function logic.

v2.1.5 patches three behavioral bugs (ImageConfig upgrades, ResourceSelector matching, circuit breaker resets) and pulls in a broad sweep of security dependency updates including Go 1.25.9.

• securityUpgrade to v2.1.5 promptly — this release addresses multiple CVEs in core dependencies

  The dependency list here is long: grpc, go-git (patched twice), go-jose, cloudflare/circl, moby/spdystream, docker/cli, and the OTel OTLP trace exporter all received security updates, plus Go itself was bumped to 1.25.9. Any of these could carry CVEs relevant to your threat model. This isn't a routine chore bump — prioritize this upgrade over staying on v2.1.4.

• breakingCheck for silently stale packages if you use ImageConfig prefix rewrites

  If your environment uses ImageConfig to rewrite registry prefixes, dependent packages may have been silently pinned at outdated versions since the bug was introduced. After upgrading to v2.1.5, verify that your package dependency graph resolves to the expected versions — stale packages won't auto-upgrade retroactively, so you may need to trigger a reinstall or version bump manually.

• enhancementResourceSelector 'select all of a kind' unlocks cleaner composition function patterns

  If you've been working around the previous rejection of bare apiVersion/kind selectors — adding dummy matchLabels or splitting logic — you can now clean that up. A selector with no match fields is treated as 'give me all resources of this kind,' which is the intuitive behavior. Review your composition functions for any workarounds and simplify them after upgrading.

v2.0.8 fixes two user-reported bugs (ImageConfig prefix rewrite upgrades, ResourceSelector with no match field) and patches multiple security vulnerabilities in upstream dependencies.

• securityUpgrade to v2.0.8 immediately for dependency security patches

  Multiple upstream dependencies received security-tagged fixes in this release — go-git (two separate bumps to v5.17.1 then v5.18.0), go-jose, cloudflare/circl, and others. These aren't just routine bumps; they carry CVE-related fixes. If you're running any v2.0.x release prior to v2.0.8, upgrade now. There are no API changes, so the upgrade path is straightforward.

• breakingAudit packages installed via ImageConfig prefix rewrites for stale dependencies

  If your environment uses ImageConfig prefix rewrites to redirect package pulls (e.g., to a private registry), dependent packages may have been silently stuck on outdated versions since you adopted that configuration. After upgrading to v2.0.8, force a reconciliation and verify that all package dependencies are on their expected versions — don't assume the upgrade alone will catch everything already in a stuck state.

• enhancementUse bare ResourceSelector (apiVersion+kind only) for 'select all' semantics in composition functions

  Previously, omitting matchName and matchLabels from a ResourceSelector caused Crossplane to reject the request outright. That's now fixed — a bare selector correctly means 'all resources of this kind'. If you worked around this limitation by enumerating resources explicitly or adding dummy match conditions, clean up those workarounds after upgrading.

v1.20.6 is a security-focused patch release fixing multiple dependency CVEs and hardening CI workflows against script injection attacks.

• securityUpgrade to v1.20.6 immediately — multiple dependency CVEs patched

  Five separate security dependency updates landed in this release, covering cryptography (circl), git operations (go-git), HTTP/2 streaming (spdystream), and telemetry export (otelhttp). Any Crossplane v1.20.x deployment is exposed until upgraded. This isn't a theoretical risk — go-git had two separate security fixes within this single patch release, which signals active exploitation concern. Run your upgrade now.

• securityCI/CD supply chain hardening — audit your own pipelines

  The Crossplane team mitigated script injection in their release promotion workflow and tightened GitHub Actions job permissions. If you're running Crossplane forks, mirrors, or custom automation that builds on top of Crossplane's CI patterns, audit your own workflows for similar issues: untrusted input in run steps and overly broad GITHUB_TOKEN permissions are the two patterns to check.

• enhancementTrivy scanning dropped from CI — don't let it drop from yours

  Crossplane dropped Trivy from their CI pipeline in this release. This is an internal CI decision, but if your team was relying on Crossplane's upstream scan results as a proxy for your own security posture, that signal is now gone. Make sure you have independent vulnerability scanning on your Crossplane images and provider images in your own pipelines.

Kubescape v4.0.5 is a routine maintenance release: Go toolchain update plus dependency bumps. No new features or bug fixes.

• securityUpgrade to pick up Go runtime and dependency CVE fixes

  Go version bumps often patch stdlib vulnerabilities (e.g., net/http, crypto) that affect compiled binaries. If you're running Kubescape as a cluster component or in CI pipelines, pull this update. Check your current version with 'kubescape version' and replace the binary or update your container image tag. Low effort, low risk.

• enhancementPin to this patch version in your automation

  If you're using Kubescape in CI/CD security scanning pipelines, update your pinned version to v4.0.5 to stay current with the dependency graph. This is especially relevant if your org has SCA tooling that flags transitive dependency staleness in scan tooling itself — a common audit finding.

v4.0.4 is a dependency maintenance release with security-relevant library bumps across gRPC, go-git, cloudflare/circl, go-jose, and hashicorp/go-getter, plus minor CLI bug fixes.

• securityUpgrade immediately due to security-sensitive dependency updates

  Several updated libraries — hashicorp/go-getter, cloudflare/circl, go-jose, and go-git — have histories of CVEs covering path traversal, cryptographic weaknesses, and JWT attacks. While Kubescape's release notes don't call out specific CVEs, the jump from go-getter 1.7.9 to 1.8.6 and go-git 5.16.5 to 5.17.1 are both large version gaps. If you run Kubescape in CI pipelines or as part of automated scanning, update to v4.0.4 now rather than waiting for a scheduled maintenance window.

• enhancementHelm 3.20.2 and gRPC 1.79.3 bring compatibility improvements

  The Helm SDK bump to 3.20.2 means Kubescape's chart scanning logic stays aligned with current Helm releases. If your clusters use recent Helm chart features, earlier Kubescape versions may have produced incomplete or inaccurate scan results. Rerun chart-level scans after upgrading to confirm coverage.

• enhancementFix for duplicate flags in `scan image` — check any wrapper scripts

  If you have shell scripts or CI configs that pass flags explicitly to `kubescape scan image`, the duplicate-flag bug could have caused unexpected behavior or silent flag ignoring. After upgrading, verify your pipeline invocations still produce expected output.

Critical security patch fixing ACL bypass via path traversal in service invocation — any deployment using access control policies must upgrade immediately.

• securityUpgrade immediately if you use service invocation ACLs

  This is a real ACL bypass, not a theoretical one. If your Dapr deployment uses access control policies for service invocation and the Dapr API is reachable by untrusted callers — even internal ones — you are vulnerable. The gRPC vector is especially dangerous since it passes method strings raw with no sanitization. Upgrade to v1.15.14 now. There is no workaround short of disabling service invocation or isolating the Dapr API entirely.

• securityAudit who can reach your Dapr API endpoints

  This vulnerability required API access, so the blast radius depends entirely on your network posture. After upgrading, take the opportunity to review which workloads and network paths can reach the Dapr HTTP and gRPC APIs. Sidecar-only access (localhost) is the safest posture — if you're exposing Dapr APIs more broadly, tighten that regardless of this fix.

• breakingVerify your service invocation method paths still route correctly after normalization

  The fix applies path.Clean normalization to all method paths and rejects any containing #, ?, null bytes, or control characters. If any of your services legitimately use encoded slashes (%2F) as path separators in method names — particularly over gRPC where these were previously passed through raw — those calls will now behave differently. Test your service-to-service invocation patterns before rolling this to production.

Argo CD v3.3.7 is a patch release fixing controller performance regressions, OIDC config handling, and several UI/security header issues.

• securitySwagger UI endpoints now have clickjacking protection — upgrade if exposed

  X-Frame-Options and Content-Security-Policy headers were missing from Swagger UI endpoints. If your Argo CD API server is reachable from browsers (even internally), those endpoints were frameable. Upgrade to 3.3.7 to close this. No config change needed post-upgrade.

• breakingOIDC auth may behave differently after upgrade if config was stale

  The fix ensures OIDC config reloads on server restart rather than using a cached/stale version. In practice this is a correctness fix, but if you've been working around stale OIDC behavior with manual pod restarts, verify SSO flows after upgrading to confirm expected behavior.

• enhancementUpgrade if you're seeing excessive reconciliation or controller CPU spikes

  Two separate fixes address controller overhead: the parentUIDToChildren data structure change reduces memory churn on large clusters, and the informer resync fix stops unnecessary app refreshes that inflate API server load. If your controller is burning CPU or you're seeing constant reconcile loops, this patch is worth prioritizing.

v1.17.5 is a security-only patch fixing a path traversal vulnerability that allowed attackers to bypass service invocation ACL policies via encoded URL characters.

• securityUpgrade immediately if you use service invocation ACLs

  Any deployment with access control policies for service invocation is vulnerable. An attacker with Dapr API access (HTTP or gRPC) could reach denied endpoints by encoding the path. gRPC is especially risky since method strings were passed raw. Upgrade to v1.17.5 now — there is no workaround short of removing Dapr API exposure entirely. After upgrading, audit your ACL policies to confirm expected paths are actually being enforced.

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix adds strict validation: method paths containing #, ?, null bytes, or control characters are now rejected at the invocation edge. If any of your services use these characters in method paths (uncommon but possible with gRPC), those calls will fail after upgrade. Test your service invocation paths in a staging environment before rolling this to production.

Critical security fix: path traversal and encoded characters in service invocation method paths could bypass ACL policies entirely. Upgrade immediately if you use access control policies.

• securityUpgrade immediately if you use Dapr ACL policies

  Any deployment with service invocation access control policies is vulnerable. An attacker with access to the Dapr HTTP or gRPC API can craft method paths that the ACL permits but route to denied endpoints. The gRPC vector is especially dangerous since no client-side sanitization occurs. Upgrade to v1.16.14 now — there is no viable workaround short of removing Dapr API access entirely. After upgrading, audit your ACL policy rules to confirm they match the normalized path forms (resolved ../ and no encoded separators).

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix actively rejects method paths containing fragment (#), query (?), null bytes, or control characters rather than silently normalizing them. If any of your services invoke methods with these characters (unlikely but possible via programmatic gRPC calls), those calls will fail after upgrading. Review your service invocation call sites — especially any that construct method paths dynamically — before rolling this out to production.