Releases

Dapr 1.18 is a large release centered on workflow security and durability (tamper detection, access policies, history propagation, concurrency limits), with Jobs API and HotReload graduating to GA and several breaking changes requiring pre-upgrade review.

• securityEnable WorkflowAccessPolicy in shared or multi-tenant clusters

  Before 1.18, any caller in the same trust domain could schedule, terminate, or query any other app's workflows. The new WorkflowAccessPolicy CRD lets you lock this down per-operation with glob-pattern rules. The default is still open (no policy = all calls allowed), so existing deployments are unaffected — but teams running shared clusters should define policies now. Also: redis common components previously skipped TLS cert verification unconditionally; this is fixed in 1.18, so verify your Redis TLS config is correct before upgrading.

• breakingDo not roll back from 1.18 directly to 1.17.6 or earlier

  Sentry 1.18 writes an Ed25519-keyed CA into the dapr-trust-bundle secret. Any Sentry version before 1.17.7 cannot parse this and will crash-loop, blocking all new certificate issuance. Before upgrading, confirm your rollback target is 1.17.7+. If you need to go below 1.17.7, downgrade to 1.17.7 first, stabilize, then continue. Also audit any code that relied on silent workflow ID reuse — it now gets a hard conflict error.

• breakingHop-by-hop headers stripped on service invocation — check your apps

  Standard HTTP hop-by-hop headers (Connection, Keep-Alive, Transfer-Encoding, etc.) are now stripped during service invocation per RFC 7230. Any app relying on these headers passing through will silently break. Audit service invocation call sites and move to non-hop-by-hop equivalents before upgrading.

• enhancementEnable workflow history signing for audit-sensitive workloads

  Workflow history signing is opt-in and disabled by default. It requires mTLS to be active. Before turning it on cluster-wide, let any in-flight unsigned workflows complete or purge them — enabling signing on a workflow that started unsigned is a hard verification error with no catch-up path. Once enabled, a tampered workflow is terminated and flagged with DAPR_WORKFLOW_HISTORY_TAMPERED, leaving the original state intact for forensic review. Good candidate for compliance-sensitive or multi-tenant workflow deployments.

v1.17.8 fixes two issues: workflows getting permanently stuck when reusing completed instance IDs, and a Sentry OIDC security flaw (CWE-346) that allows discovery document poisoning via X-Forwarded-Host.

• securityFix OIDC discovery document poisoning via X-Forwarded-Host

  Sentry OIDC deployments running without `--jwt-issuer` or `--oidc-allowed-hosts` are vulnerable to CWE-346: an attacker who can send requests with a forged `X-Forwarded-Host` header can poison the discovery document, and HTTP caches may serve the poisoned response for up to an hour. If you can't upgrade immediately, set `--jwt-issuer` (pins the issuer statically, simplest fix) or `--oidc-allowed-hosts`. If you use a reverse proxy that needs to advertise its public hostname via `X-Forwarded-Host`, set `--oidc-allowed-hosts` to your expected hostname — this is now required for that header to take effect.

• breakingUpgrade to fix stuck workflows with reused instance IDs

  Any workflow using deterministic/stable instance IDs is affected. After upgrading sidecars to 1.17.8, stuck workflows recover automatically on the next retention reminder fire — no manual scheduler cleanup needed. Check your `dapr_runtime_workflow_operation_count{operation=purge_workflow,status=failed}` metric; if it's incrementing at ~1/sec per workflow, you're hitting this bug.

Dapr v1.17.7 is a dense bug-fix release targeting workflow reliability, messaging correctness, and control-plane resilience. Fourteen production-grade fixes land here — upgrade if you run workflows, Kafka, or RabbitMQ.

• securityUpgrade sentry immediately if you downgraded from 1.18 or use Ed25519/RSA issuer keys

  A type-switch bug in dapr/kit caused sentry to crash on startup with 'unsupported key type' for Ed25519 and RSA issuer keys. Sentry enters a crash-loop, stops issuing mTLS identities, and halts cert rotation. Sidecars with unexpired certs keep running, but any pod restart or cert expiry silently breaks identity. If your trust bundle was generated by 1.18 or you manually rotated to Ed25519/RSA keys, this is a crash-loop waiting to happen. Upgrading to 1.17.7 is the only fix — no trust bundle migration needed.

• breakingScheduler etcd compaction mode change requires PVC capacity review

  The embedded etcd compaction mode switches from periodic (10 min) to revision-based (1,000,000 revisions), and the default storage size jumps from 1Gi to 16Gi. Kubernetes StatefulSet volumeClaimTemplates are immutable, so existing 1Gi PVCs are NOT automatically resized. If you're running the scheduler at any real workflow throughput, check your current PVC utilization now. If you're close to capacity, expand the PVC on the cluster before upgrading. The helm chart uses a lookup helper to avoid overwriting existing PVC sizes, but it cannot expand them for you.

• enhancementAdd workflow payload size ratio dashboards before upgrading

  Two new histograms — dapr_runtime_workflow_payload_size_ratio and dapr_runtime_workflow_activity_payload_size_ratio — report payload size as a fraction of --max-body-size. Before upgrading, set up a Prometheus alert on histogram_quantile(0.99, ...) > 0.9 so you catch workflows trending toward the 0.95 stall threshold before they freeze. This is especially useful for workflows with large activity payloads or long histories. Note: metrics are only recorded when --max-body-size is explicitly configured.

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.

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.

Dapr v1.16.13 fixes a critical scheduler reliability bug affecting multi-replica deployments, patches a silent Pulsar misconfiguration that could cause OOM crashes, and rebuilds with Go 1.25.9 for security fixes.

• securityUpgrade immediately for Go 1.25.9 security patches

  This build patches vulnerabilities in Go's crypto/x509, crypto/tls, archive/tar, and html/template packages. Any Dapr deployment still on 1.16.12 or earlier is exposed. Upgrade to 1.16.13 now — there's no workaround short of rebuilding from source with Go 1.25.9 yourself.

• breakingPulsar users: processMode will now actually take effect — verify your config

  If you have processMode set in your Pulsar component YAML, it was silently ignored before this release. After upgrading, that config will be enforced. If you set processMode: sync expecting ordered processing but were actually running async, behavior changes on upgrade. Review your Pulsar component metadata and subscription behavior before rolling this out to production. Also check maxConcurrentHandlers: if it was set to 0, it previously caused a deadlock; now it falls back to 100.

• breakingMulti-replica scheduler deployments: patch this immediately

  The scheduler bug is severe in practice. A routine pod restart — due to a rolling update, OOM kill, or node eviction — would silently stop all job triggers across your deployment until some unrelated cluster event re-established connections. There's no alerting or visible failure; jobs just stop firing. If you run multiple scheduler replicas (standard HA setup), this fix is critical. Upgrade and verify your scheduled jobs are firing after any scheduler pod restart.

Dapr 1.17.4 patches seven bugs spanning workflow correctness, Pulsar OOM risk, actor freeze under placement pressure, and a Go stdlib security update. Deploy promptly if you use any of these features.

• securityUpgrade immediately for Go stdlib CVE fixes

  Go 1.25.9 patches vulnerabilities in archive/tar, crypto/tls, crypto/x509, html/template, and the compiler. All Dapr binaries and Docker images are rebuilt with the patched toolchain. Update your Dapr runtime to 1.17.4 now — no config changes needed, just the version bump.

• breakingPulsar processMode behavior has changed — validate your component config

  If you set processMode in Pulsar component YAML before this fix, it was silently ignored and you were running in default mode. After upgrading, the setting takes effect. If you had processMode: sync expecting ordered processing but were unknowingly running async, behavior will change. Also, async mode now caps concurrency at maxConcurrentHandlers (default 100). Review your Pulsar component metadata and test throughput behavior before rolling to production.

• enhancementEliminate actor/workflow freeze risk from placement slowness

  The placement dissemination freeze bug could cause cascading health check failures during rolling updates — Kubernetes would declare pods unhealthy and restart them, worsening the cycle. With 1.17.4, a slow peer triggers reconnect rather than a fatal teardown. If you've seen unexplained actor hangs or zombie daprd processes during rollouts, this is likely the cause. No configuration change needed; upgrading is sufficient.

Dapr v1.16.12 patches a gRPC auth bypass CVE, fixes broken Pulsar Avro/JSON schema handling that blocked message delivery, and resolves a Scheduler cluster stall lasting up to 20 minutes after pod restarts.

• securityUpgrade immediately to patch gRPC auth bypass (CVE-2026-33186)

  CVE-2026-33186 allows unauthorized gRPC requests to bypass authorization under certain conditions. This affects all Dapr 1.16.x versions prior to 1.16.12. Upgrade now — there's no workaround that doesn't involve patching the dependency.

• breakingPulsar Avro + CloudEvents schema registration has changed — existing topics may need attention

  If you're running Dapr 1.16.0–1.16.11 with Pulsar topics using Avro schemas and CloudEvents wrapping (the default), the schema registered in Pulsar's Schema Registry was wrong. After upgrading, new schema registrations will use the correct CloudEvents envelope Avro schema. Check whether existing Pulsar topics have mismatched schemas in the registry and whether downstream non-Dapr consumers are affected. Use the new rawSchema metadata option only for topics intentionally serving raw payloads.

• enhancementScheduler HA deployments are no longer vulnerable to 20-minute stalls on pod restart

  Any HA Dapr deployment (3 Scheduler instances) with active workflows or actor reminders was at risk of a silent 20-minute outage after a pod restart. The fix makes engine shutdown context-aware, so in-flight triggers cancel immediately and the cluster re-establishes quorum in seconds. If you've been observing unexplained workflow/reminder gaps after rolling updates or node maintenance, this is the cause. Upgrade and also note that Dapr v1.17 redesigned the trigger path entirely to avoid this class of problem.

Dapr v1.17.3 patches two CVEs (gRPC auth bypass, TIFF OOM DoS) and fixes several high-impact runtime bugs including actor response data loss over h2c, a cascading placement failure, and a scheduler silent-stop bug.

• securityUpgrade immediately for two active CVEs

  CVE-2026-33186 allows gRPC authorization bypass — unauthorized requests could reach your services. CVE-2026-33809 allows a malicious 8-byte TIFF file to trigger ~4GB memory allocation and OOM-crash a sidecar. Both are fixed only in v1.17.3. There is no workaround short of upgrading. Treat this as an urgent patch, especially if your Dapr components process any image data or expose gRPC endpoints to untrusted callers.

• breakingActor + h2c users were silently losing response data — verify your setup

  If you run actors with --app-protocol h2c, every actor method invocation since v1.17.2 could have returned HTTP 200 with an empty body. Your app received no error, just missing data. After upgrading to v1.17.3, audit any actor calls that might have been silently failing and verify response payloads are intact. If you log or cache actor responses, replay or revalidate any data collected since upgrading to v1.17.2.

• enhancementHA Scheduler deployments: restart pods after upgrade to clear stale leadership state

  The scheduler silent-stop bug left stale etcd leadership keys that block quorum convergence. After upgrading, do a coordinated restart of all Scheduler pods to force a clean leadership election. Going forward, workflow timers, scheduled jobs, and actor reminders should be reliable after rolling updates. If you previously saw reminders or jobs randomly stop firing after a Scheduler pod restart, this is the fix.

Three critical Scheduler HA bugs fixed — cascading crashes, silent partition stalls, and Windows AKS sidecar failures — plus a Go security bump to 1.25.8.

• securityGo 1.25.8 security patches — rebuild or upgrade

  Go 1.25.8 fixes vulnerabilities in html/template, net/url, and os packages. If you're running Dapr v1.16.10 or earlier, the binary was built against a patched Go version that still carries these issues. Upgrading to v1.16.11 picks up the fixed runtime automatically. If you also maintain custom Dapr-adjacent services built with Go 1.25.7, rebuild those separately.

• breakingUpgrade immediately if running Scheduler in HA mode

  Any multi-instance Scheduler deployment on v1.16.0–v1.16.10 is exposed to two distinct failure modes: a cascading crash under high job load, and a silent stall where instances hold partition leases but never fire jobs. Both require restarting all Scheduler pods to recover. Neither has a workaround short of upgrading. If you're running Dapr Workflows, actor reminders, or scheduled jobs in HA, treat this as urgent — workflows can stop firing entirely after a routine pod eviction or rolling update.

• breakingWindows AKS users: broken since v1.16.9, fixed here

  If you deployed Dapr on AKS Windows nodes between v1.16.9 and v1.16.10, your daprd sidecars have been stuck in CrashLoopBackOff. The root cause was a Docker manifest tooling change that dropped the os.version field, causing the Windows container runtime to pull the wrong image variant. Upgrading to v1.16.11 restores correct behavior — no manifest or config changes needed on your end.

Dapr v1.17.2 is a high-priority patch with three Go stdlib CVE fixes, a CRD breaking change requiring manual update, and fixes for cascading actor placement failures and streaming OOM issues.

• securityUpgrade immediately to patch three Go stdlib CVEs

  Go 1.24.x carried GO-2026-4601 (IPv6 SSRF via net/url), GO-2026-4602 (path escape via os.Root), and GO-2026-4603 (XSS via html/template). If your Dapr sidecars handle user-supplied URLs or template rendering in any adjacent service, exposure is real. Upgrade to v1.17.2 now — the fix is a Go toolchain bump, so no code changes are needed on your end.

• breakingManually update CRDs before Helm upgrade or daprd will fail to start

  The `stateRetentionPolicy` fields in the Configuration CRD changed from `type: integer` to `type: string`. Helm does not update CRDs automatically. If you run `helm upgrade` without updating the CRD first, any existing Configuration objects using duration strings will fail Kubernetes validation and daprd may fail to load its config. Run the CRD update step from the Kubernetes upgrade guide before touching Helm. If you're not using workflow state retention policies today, the risk is lower, but update the CRD anyway to stay consistent.

• enhancementLarge actor deployments and streaming workloads should prioritize this patch

  Two fixes deserve immediate attention beyond security. First, deployments with 50+ actor replicas were hitting cascading dissemination timeouts in 1.17.x — the placement service batching fix in this release resolves that. Second, any service invocation path passing large or streaming bodies (file uploads, SSE, chunked data) was silently OOM-killing sidecars by buffering everything in memory. Both are now fixed. If either pattern applies to your workload, treat this upgrade as urgent rather than routine.

Dapr 1.16.10 fixes critical WASM component registration failures on production architectures and patches security vulnerabilities in Go runtime and OpenTelemetry SDK.

• securityUpdate for Go runtime and OpenTelemetry security patches

  This release patches vulnerabilities in Go 1.25.7 (crypto/tls, go command) and OpenTelemetry SDK (arbitrary code execution via PATH hijacking). Plan your upgrade within your normal security patching window, prioritizing environments where PATH manipulation is possible.

• breakingUpgrade immediately if using WASM components

  WASM binding and middleware components have been completely broken on production architectures since v1.16.0. If you're using these components and running v1.16.0-v1.16.9, upgrade to v1.16.10 immediately as your WASM components are silently failing to register.

• enhancementReview Pulsar Avro message publishing for early error detection

  Pulsar PubSub now validates JSON messages against Avro schemas before publishing, catching malformed data earlier. Test your Pulsar publishing workflows to ensure they handle the new validation errors gracefully and benefit from faster codec performance.