n8n [email protected], published on July 24, 2026, corrects S3 object path signing by applying strict RFC 3986 encoding. This is a standard release, not a prerelease, and its documented scope is one core fix for canonical object paths.
The full release notes and downloads are on the GitHub release page.
S3 paths now use strict RFC 3986 encoding ¶
The release changes how the n8n core signer encodes an S3 object path before authentication. With a signed S3 request, the path used to construct the canonical request must agree with the path sent to the storage endpoint. A difference in encoding can produce a signature mismatch even when the credentials, bucket, and object key are otherwise correct.
Strict RFC 3986 encoding matters when an object key contains bytes that also have meaning in a URI. The release notes do not enumerate affected characters or identify a particular storage vendor. Operators should therefore read this as a standards compliance fix, not as a vendor specific compatibility claim.
The project tracks the bug in issue 34871. The implementation is available in commit 95ad6f6. Those are the only functional details attached to this release, so there is no broader feature set to infer from the version number.
What this changes for workflow data ¶
Object keys often come from workflow data rather than static configuration. File names, generated identifiers, dates, customer supplied labels, and nested folder names can all become part of an S3 path. A path encoding defect can therefore appear only for a subset of records, which makes it look like a data quality problem rather than a signing problem.
For platform operators, the useful distinction is that this fix targets request correctness. The notes provide no throughput claim, storage schema change, queue behavior change, or workflow execution change. Existing workloads that only use simple object keys may show no visible difference after the update.
The narrow scope also limits the expected blast radius. There is no documented migration step and no configuration key to change. Still, any local workaround that normalizes or rewrites object keys deserves review after deployment. A workaround may now alter a valid key even though the signer can encode it correctly.
Deployment checks for S3 backed workflows ¶
Test the release against the same S3 endpoint used in production. Include a representative set of object keys with spaces, plus signs, percent signs, and nested path segments. Exercise each operation your workflows depend on, such as creating, reading, and deleting an object, then inspect authentication failures separately from missing object responses.
A staged rollout is appropriate when object keys are derived from external input. Compare failures before and after the update, especially errors that report a signature mismatch or an invalid canonical request. Keep any key normalization workaround in place until the updated signer has handled the existing test corpus successfully.
This release is not marked as a prerelease. The notes do not describe a breaking change, but the signing path is shared core behavior, so a canary remains more useful than assuming that a one line release note implies zero operational risk.