You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A validation bypass vulnerability exists in Fastify where request body validation schemas specified by Content-Type can be completely circumvented. By appending a tab character (\t) followed by arbitrary content to the Content-Type header, attackers can bypass body validation while the server still processes the body as the original content type.
For example, a request with Content-Type: application/json\ta will bypass JSON schema validation but still be parsed as JSON.
This vulnerability affects all Fastify users who rely on Content-Type-based body validation schemas to enforce data integrity or security constraints. The concrete impact depends on the handler implementation and the level of trust placed in the validated request body, but at the library level, this allows complete bypass of body validation for any handler using Content-Type-discriminated schemas.
This issue is a regression or missed edge case from the fix for a previously reported vulnerability.
Patches
This vulnerability has been patched in Fastify v5.7.2. All users should upgrade to this version or later immediately.
Workarounds
If upgrading is not immediately possible, user can implement a custom onRequest hook to reject requests containing tab characters in the Content-Type header:
A Denial of Service vulnerability in Fastify’s Web Streams response handling can allow a remote client to exhaust server memory. Applications that return a ReadableStream (or Response with a Web Stream body) via reply.send() are impacted. A slow or non-reading client can trigger unbounded buffering when backpressure is ignored, leading to process crashes or severe degradation.
Patches
The issue is fixed in Fastify 5.7.3. Users should upgrade to 5.7.3 or later.
Workarounds
Avoid sending Web Streams from Fastify responses (e.g., ReadableStream or Response bodies). Use Node.js streams (stream.Readable) or buffered payloads instead until the project can upgrade.
When trustProxy is configured with a restrictive trust function (e.g., a specific IP like trustProxy: '10.0.0.1', a subnet, a hop count, or a custom function), the request.protocol and request.host getters read X-Forwarded-Proto and X-Forwarded-Host headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application.
Affected Versions
fastify <= 5.8.2
Impact
Applications using request.protocol or request.host for security decisions (HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, host-based routing) are affected when trustProxy is configured with a restrictive trust function.
When trustProxy: true (trust everything), both host and protocol trust all forwarded headers — this is expected behavior. The vulnerability only manifests with restrictive trust configurations.
fastify before 5.12.1, when a route uses a root-level primitive body schema (for example an integer with a minimum and maximum) and the default type coercion, validates the coerced value but exposes the original, uncoerced value to the route handler. For example, a JSON body "10" is coerced to the number 10 and passes an integer 1 to 10 schema, but request.body stays the string "10". An application that trusts the validated type is handed a value that did not satisfy the schema, which can bypass limits the application enforces on that typed value. Object and array body schemas are not affected, they coerce their members in place.
Patches
Upgrade to fastify 5.12.1.
Workarounds
Until you can upgrade, avoid relying on the validated type of a root primitive body. Wrap the value in an object schema (object properties are coerced in place), for example accept { "value": 10 } and read request.body.value, or re-check the type in the handler.
Fastify routes a malformed URL under one plugin prefix to the custom not-found handler of a different sibling plugin, invoking the handler registered last and skipping the preHandler declared in its setNotFoundHandler(). When the request method has no route in the main router, a malformed request target reaches Fastify's internal not-found router before URL decoding and is dispatched through a single shared handler pointer, regardless of prefix and without the normal request lifecycle. An unauthenticated request to a public prefix can therefore reach an authentication-protected not-found handler registered under a different prefix and receive its full response, breaking prefix encapsulation and bypassing the authentication hook. Applications whose private or tenant fallbacks return protected data from a not-found handler are affected.
Patches
Patched in fastify 5.12.2. Malformed URLs are now routed through the configured onBadUrl and onMaxParamLength handlers so they fail closed before any application not-found handler runs, and the shared not-found handler pointer has been removed.
Workarounds
Reject malformed request targets before they reach the application, for example at an upstream proxy or gateway, and do not rely on a not-found handler to serve protected data. A global onRequest authentication hook does not mitigate this, because the malformed-URL path skips it.
Fastify decided whether to validate a request part by checking its schema for JavaScript truthiness. JSON Schema Draft 7 defines the boolean false as a valid schema that rejects every instance, but because false is falsy, a route that set body, querystring, params, or headers to false had that part left uncompiled: no validator was attached and the request reached the handler. An application that used false as a deny-all schema to make a route unreachable was therefore fully bypassed, and an unauthenticated remote client could reach the handler with any input. The same applied to the documented query alias for querystring. This is a complete bypass rather than a weak-schema issue, since false is the strongest JSON Schema assertion and must always fail.
Patches
Request-part schemas are now selected by an explicit presence check rather than truthiness, so a boolean false (or true) schema is compiled and enforced, including through the query alias. Patched in fastify 5.12.2. The fix is also included in the 6.0.0 release.
Workarounds
If upgrading is not immediately possible, express a deny-all request schema with an always-failing object schema instead of the boolean false (for example { "not": {} }), or reject the request in an onRequest hook.
Fastify runs a route's validator and, for a result shaped like { value, error }, unwraps it: an error becomes a validation failure and value replaces the request part. This convention is intended for synchronous custom compilers (for example Joi). A JSON Schema $async validator, however, resolves with the validated data itself, so Fastify applied the same unwrapping to it. If a request part validated by an $async schema contains a value property, Fastify replaced the whole request part with that nested value before the handler ran, so a value or error property in the payload was attacker-controlled. An application that dispatches operations from the validated request body could then act on data that never satisfied the route schema, leading to unauthorized state changes or disclosure. Reaching the vulnerable path requires the route to use an $async request schema.
Patches
Fastify no longer treats an asynchronous validation result as a { value, error } wrapper: an async validator's resolved value is used only to determine pass or fail, and it can no longer replace the request part or inject an error. The synchronous custom-compiler contract is unchanged. Patched in fastify 5.12.2 and 6.0.0.
Workarounds
If upgrading is not immediately possible, avoid $async request schemas, or perform the security-sensitive check in an onRequest or preHandler hook rather than relying on the schema-validated request part. Custom async validator compilers should signal failure by throwing (rejecting) rather than returning an { error } object.
Fastify lowercases header-schema property names before compiling the schema, because Node.js stores request header names in lowercase. That normalization was incomplete: it lowercased only top-level properties keys and the root required array, and did not lowercase the JSON Schema Draft 7 dependencies keyword (its trigger keys and dependent property names) or names in nested subschemas. As a result, a header schema that uses dependencies to require one header when another is present (for example X-Admin requiring X-Admin-Token) never matches the lowercased request headers, so the dependency assertion is silently skipped. An unauthenticated remote client can send the header that activates a privileged path while omitting the header the dependency was meant to require, bypassing a schema-enforced security control. The header schema is idiomatic, valid JSON Schema Draft 7, and no custom validator, malformed request, or misconfiguration is required.
Patches
Header-schema names are now normalized across all schema positions (properties, required, dependencies, dependentRequired, dependentSchemas, and nested subschemas). Patched in fastify 5.12.2. The fix is also included in the 6.0.0 release. Header schemas referenced through an external shared $ref (registered with addSchema) are not reached by this normalization and now emit an FSTSEC002 startup warning; inline the header schema to keep case-insensitive assertions in effect.
Workarounds
If upgrading is not immediately possible, write header-schema names in lowercase so the dependencies and other case-sensitive assertions match Node's lowercased request headers, or enforce the cross-header requirement in an onRequest or preValidation hook instead of the schema.
fastify crashes with an uncaught ERR_HTTP2_INVALID_CONNECTION_HEADERS exception when a route that registers a response trailer via reply.trailer() is served over HTTP/2. Fastify unconditionally adds the Transfer-Encoding: chunked header when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process.
One unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and the request can be repeated to keep the process down. Applications are affected only when HTTP/2 is enabled (http2: true) and at least one route registers a trailer. HTTP/1.x responses are not affected.
Patches
Upgrade to fastify5.12.5 or later.
Workarounds
Avoid registering response trailers with reply.trailer() on routes served over HTTP/2 until upgrading.
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:
any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually
The artifact failure details are included below:
File name: package-lock.json
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: @fastify/awilix@3.2.0
npm ERR! Found: fastify@5.12.5
npm ERR! node_modules/fastify
npm ERR! fastify@"^5.0.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer fastify@"^4.0.0" from @fastify/awilix@3.2.0
npm ERR! node_modules/@fastify/awilix
npm ERR! @fastify/awilix@"^3.1.0" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: fastify@4.29.1
npm ERR! node_modules/fastify
npm ERR! peer fastify@"^4.0.0" from @fastify/awilix@3.2.0
npm ERR! node_modules/@fastify/awilix
npm ERR! @fastify/awilix@"^3.1.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /runner/cache/others/npm/eresolve-report.txt for a full report.
npm ERR! A complete log of this run can be found in:
npm ERR! /runner/cache/others/npm/_logs/2026-10-06T15_15_14_389Z-debug-0.log
Comment @coderabbitai help to get the list of available commands.
renovateBot
changed the title
fix(deps): update dependency fastify to v5 [security]
fix(deps): update dependency fastify to v5 [security] - autoclosed
Mar 27, 2026
renovateBot
changed the title
fix(deps): update dependency fastify to v5 [security] - autoclosed
fix(deps): update dependency fastify to v5 [security]
Mar 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^4.20.0→^5.0.0Fastify's Content-Type header tab character allows body validation bypass
CVE-2026-25223 / GHSA-jx2c-rxcm-jvmq
More information
Details
Impact
A validation bypass vulnerability exists in Fastify where request body validation schemas specified by Content-Type can be completely circumvented. By appending a tab character (
\t) followed by arbitrary content to the Content-Type header, attackers can bypass body validation while the server still processes the body as the original content type.For example, a request with
Content-Type: application/json\tawill bypass JSON schema validation but still be parsed as JSON.This vulnerability affects all Fastify users who rely on Content-Type-based body validation schemas to enforce data integrity or security constraints. The concrete impact depends on the handler implementation and the level of trust placed in the validated request body, but at the library level, this allows complete bypass of body validation for any handler using Content-Type-discriminated schemas.
This issue is a regression or missed edge case from the fix for a previously reported vulnerability.
Patches
This vulnerability has been patched in Fastify v5.7.2. All users should upgrade to this version or later immediately.
Workarounds
If upgrading is not immediately possible, user can implement a custom
onRequesthook to reject requests containing tab characters in the Content-Type header:Resources
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Fastify Vulnerable to DoS via Unbounded Memory Allocation in sendWebStream
CVE-2026-25224 / GHSA-mrq3-vjjr-p77c
More information
Details
Impact
A Denial of Service vulnerability in Fastify’s Web Streams response handling can allow a remote client to exhaust server memory. Applications that return a
ReadableStream(orResponsewith a Web Stream body) viareply.send()are impacted. A slow or non-reading client can trigger unbounded buffering when backpressure is ignored, leading to process crashes or severe degradation.Patches
The issue is fixed in Fastify 5.7.3. Users should upgrade to 5.7.3 or later.
Workarounds
Avoid sending Web Streams from Fastify responses (e.g.,
ReadableStreamorResponsebodies). Use Node.js streams (stream.Readable) or buffered payloads instead until the project can upgrade.References
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fastify: request.protocol and request.host Spoofable via X-Forwarded-Proto/Host from Untrusted Connections
CVE-2026-3635 / GHSA-444r-cwp2-x5xf
More information
Details
Summary
When
trustProxyis configured with a restrictive trust function (e.g., a specific IP liketrustProxy: '10.0.0.1', a subnet, a hop count, or a custom function), therequest.protocolandrequest.hostgetters readX-Forwarded-ProtoandX-Forwarded-Hostheaders from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application.Affected Versions
fastify <= 5.8.2
Impact
Applications using
request.protocolorrequest.hostfor security decisions (HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, host-based routing) are affected whentrustProxyis configured with a restrictive trust function.When
trustProxy: true(trust everything), bothhostandprotocoltrust all forwarded headers — this is expected behavior. The vulnerability only manifests with restrictive trust configurations.Severity
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fastify vulnerable to schema validation bypass via root primitive coercion mismatch
CVE-2026-18504 / GHSA-w2qp-rph6-63g4
More information
Details
Impact
fastifybefore 5.12.1, when a route uses a root-level primitive body schema (for example an integer with a minimum and maximum) and the default type coercion, validates the coerced value but exposes the original, uncoerced value to the route handler. For example, a JSON body"10"is coerced to the number10and passes an integer 1 to 10 schema, butrequest.bodystays the string"10". An application that trusts the validated type is handed a value that did not satisfy the schema, which can bypass limits the application enforces on that typed value. Object and array body schemas are not affected, they coerce their members in place.Patches
Upgrade to
fastify5.12.1.Workarounds
Until you can upgrade, avoid relying on the validated type of a root primitive body. Wrap the value in an object schema (object properties are coerced in place), for example accept
{ "value": 10 }and readrequest.body.value, or re-check the type in the handler.Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fastify vulnerable to authentication bypass via malformed URLs reaching encapsulated not-found handlers
CVE-2026-76169 / GHSA-p68q-wchp-6fh7
More information
Details
Impact
Fastify routes a malformed URL under one plugin prefix to the custom not-found handler of a different sibling plugin, invoking the handler registered last and skipping the
preHandlerdeclared in itssetNotFoundHandler(). When the request method has no route in the main router, a malformed request target reaches Fastify's internal not-found router before URL decoding and is dispatched through a single shared handler pointer, regardless of prefix and without the normal request lifecycle. An unauthenticated request to a public prefix can therefore reach an authentication-protected not-found handler registered under a different prefix and receive its full response, breaking prefix encapsulation and bypassing the authentication hook. Applications whose private or tenant fallbacks return protected data from a not-found handler are affected.Patches
Patched in fastify 5.12.2. Malformed URLs are now routed through the configured
onBadUrlandonMaxParamLengthhandlers so they fail closed before any application not-found handler runs, and the shared not-found handler pointer has been removed.Workarounds
Reject malformed request targets before they reach the application, for example at an upstream proxy or gateway, and do not rely on a not-found handler to serve protected data. A global
onRequestauthentication hook does not mitigate this, because the malformed-URL path skips it.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fastify vulnerable to request validation bypass via skipped boolean false schemas
CVE-2026-84469 / GHSA-hwr6-493r-vm6h
More information
Details
Impact
Fastify decided whether to validate a request part by checking its schema for JavaScript truthiness. JSON Schema Draft 7 defines the boolean
falseas a valid schema that rejects every instance, but becausefalseis falsy, a route that setbody,querystring,params, orheaderstofalsehad that part left uncompiled: no validator was attached and the request reached the handler. An application that usedfalseas a deny-all schema to make a route unreachable was therefore fully bypassed, and an unauthenticated remote client could reach the handler with any input. The same applied to the documentedqueryalias forquerystring. This is a complete bypass rather than a weak-schema issue, sincefalseis the strongest JSON Schema assertion and must always fail.Patches
Request-part schemas are now selected by an explicit presence check rather than truthiness, so a boolean
false(ortrue) schema is compiled and enforced, including through thequeryalias. Patched in fastify5.12.2. The fix is also included in the6.0.0release.Workarounds
If upgrading is not immediately possible, express a deny-all request schema with an always-failing object schema instead of the boolean
false(for example{ "not": {} }), or reject the request in anonRequesthook.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fastify vulnerable to request body replacement via an async validation result collision
CVE-2026-84504 / GHSA-667r-xxjv-c9mm
More information
Details
Impact
Fastify runs a route's validator and, for a result shaped like
{ value, error }, unwraps it: anerrorbecomes a validation failure andvaluereplaces the request part. This convention is intended for synchronous custom compilers (for example Joi). A JSON Schema$asyncvalidator, however, resolves with the validated data itself, so Fastify applied the same unwrapping to it. If a request part validated by an$asyncschema contains avalueproperty, Fastify replaced the whole request part with that nested value before the handler ran, so avalueorerrorproperty in the payload was attacker-controlled. An application that dispatches operations from the validated request body could then act on data that never satisfied the route schema, leading to unauthorized state changes or disclosure. Reaching the vulnerable path requires the route to use an$asyncrequest schema.Patches
Fastify no longer treats an asynchronous validation result as a
{ value, error }wrapper: an async validator's resolved value is used only to determine pass or fail, and it can no longer replace the request part or inject an error. The synchronous custom-compiler contract is unchanged. Patched in fastify5.12.2and6.0.0.Workarounds
If upgrading is not immediately possible, avoid
$asyncrequest schemas, or perform the security-sensitive check in anonRequestorpreHandlerhook rather than relying on the schema-validated request part. Custom async validator compilers should signal failure by throwing (rejecting) rather than returning an{ error }object.Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fastify vulnerable to header validation bypass via incomplete schema case normalization
CVE-2026-84428 / GHSA-9q9j-q6p8-xq58
More information
Details
Impact
Fastify lowercases header-schema property names before compiling the schema, because Node.js stores request header names in lowercase. That normalization was incomplete: it lowercased only top-level
propertieskeys and the rootrequiredarray, and did not lowercase the JSON Schema Draft 7dependencieskeyword (its trigger keys and dependent property names) or names in nested subschemas. As a result, a header schema that usesdependenciesto require one header when another is present (for exampleX-AdminrequiringX-Admin-Token) never matches the lowercased request headers, so the dependency assertion is silently skipped. An unauthenticated remote client can send the header that activates a privileged path while omitting the header the dependency was meant to require, bypassing a schema-enforced security control. The header schema is idiomatic, valid JSON Schema Draft 7, and no custom validator, malformed request, or misconfiguration is required.Patches
Header-schema names are now normalized across all schema positions (
properties,required,dependencies,dependentRequired,dependentSchemas, and nested subschemas). Patched in fastify5.12.2. The fix is also included in the6.0.0release. Header schemas referenced through an external shared$ref(registered withaddSchema) are not reached by this normalization and now emit anFSTSEC002startup warning; inline the header schema to keep case-insensitive assertions in effect.Workarounds
If upgrading is not immediately possible, write header-schema names in lowercase so the
dependenciesand other case-sensitive assertions match Node's lowercased request headers, or enforce the cross-header requirement in anonRequestorpreValidationhook instead of the schema.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fastify vulnerable to Denial of Service via unhandled exception on HTTP/2 trailer responses
CVE-2026-92081 / GHSA-4mh8-r7rc-xpvc
More information
Details
Impact
fastifycrashes with an uncaughtERR_HTTP2_INVALID_CONNECTION_HEADERSexception when a route that registers a response trailer viareply.trailer()is served over HTTP/2. Fastify unconditionally adds theTransfer-Encoding: chunkedheader when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process.One unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and the request can be repeated to keep the process down. Applications are affected only when HTTP/2 is enabled (
http2: true) and at least one route registers a trailer. HTTP/1.x responses are not affected.Patches
Upgrade to
fastify5.12.5or later.Workarounds
Avoid registering response trailers with
reply.trailer()on routes served over HTTP/2 until upgrading.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
fastify/fastify (fastify)
v5.12.5Compare Source
What's Changed
Full Changelog: fastify/fastify@v5.12.4...v5.12.5
v5.12.4Compare Source
Fixed the
fastify.jsversion mismatch.Full Changelog: fastify/fastify@v5.12.2...v5.12.4
v5.12.3Compare Source
v5.12.2Compare Source
What's Changed
Full Changelog: fastify/fastify@v5.12.1...v5.12.2
v5.12.1Compare Source
What's Changed
Full Changelog: fastify/fastify@v5.12.0...v5.12.1
v5.12.0Compare Source
What's Changed
Reply.prototype.mediaTypeby @github-actions[bot] in #6946undefinedfor invalid media types by @github-actions[bot] in #6947Full Changelog: fastify/fastify@v5.11.3...v5.12.0
v5.11.3Compare Source
What's Changed
New Contributors
Full Changelog: fastify/fastify@v5.11.2...v5.11.3
v5.11.2Compare Source
What's Changed
fastify.jsFull Changelog: fastify/fastify@v5.11.1...v5.11.2
v5.11.1Compare Source
What's Changed
New Contributors
Full Changelog: fastify/fastify@v5.11.0...v5.11.1
v5.11.0Compare Source
What's Changed
Content-Typeparameter values by @aquie00t in #6865New Contributors
Full Changelog: fastify/fastify@v5.10.0...v5.11.0
v5.10.0Compare Source
What's Changed
jsonandcharsetin reply.send by @climba03003 in #6830New Contributors
Full Changelog: fastify/fastify@v5.9.0...v5.10.0
v5.9.0Compare Source
What's Changed
findwithsomeinhasKeyfor correct boolean semantics by @aquie00t in #6759AssertionErrorwithFST_ERR_PLUGIN_DEPENDENCY_NOT_REGISTEREDincheckDependenciesby @aquie00t in #6774Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.