Impact Elysia cookie can be overridden by prototype pollution , eg. proto

Sending cookie with the follows name can override cookie value: bash proto=%7B%22injected%22%3A%22polluted%22%7D

Patches Patched by 1.4.27

Workarounds 1. Use t.Cookie validation to enforce validation value 2. Prevent iterable over cookie if possible

Impact t.String({ format: 'url' }) is vulnerable to redos

Repeating a partial url format (protocol and hostname) multiple times cause regex to slow down significantly js 'http://a'.repeat(n)

Here's a table demonstrating how long it takes to process repeated partial url format | n repeat | elapsedms | | --- | --- | | 1024 | 33.993 | | 2048 | 134.357 | | 4096 | 537.608 | | 8192 | 2155.842 | | 16384 | 8618.457 | | 32768 | 34604.139 |

Patches Patched by 1.4.26, please kindly update elysia to >= 1.4.26

Here's how long it takes after the patch | n repeat | elapsedms | | --- | --- | | 1024 | 0.194 | | 2048 | 0.274 | | 4096 | 0.455 | | 8192 | 0.831 | | 16384 | 1.632 | | 32768 | 3.052 |

Workarounds 1. It's recommended to always limit URL format to a reasonable length ts t.String({ format: 'url', maxLength: 288 })

2. If a long URL format is necessary, to patch this without updating to 1.4.26, add the following code to any part of your codebase js import { FormatRegistry } from '@sinclair/typebox'

FormatRegistry.Delete('url') FormatRegistry.Set('url', (value) => /^(?:https?|ftp):\/\/(?:[^\s:@]+(?::[^\s@])?@)?(?:(?!(?:10|127)(?:\.\d{1,3}){3})(?!(?:169\.254|192\.168)(?:\.\d{1,3}){2})(?!172\.(?:1[6-9]|2\d|3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d?|1\d\d|2[01]\d|22[0-3])(?:\.(?:1?\d{1,2}|2[0-4]\d|25[0-5])){2}(?:\.(?:[1-9]\d?|1\d\d|2[0-4]\d|25[0-4]))|(?:(?:[a-z0-9\u{00a1}-\u{ffff}]+-)[a-z0-9\u{00a1}-\u{ffff}]+)(?:\.(?:[a-z0-9\u{00a1}-\u{ffff}]+-)[a-z0-9\u{00a1}-\u{ffff}]+)(?:\.(?:[a-z\u{00a1}-\u{ffff}]{2,})))(?::\d{2,5})?(?:\/[^\s])?$/iu.test( value ) )

Arbitrary code execution from cookie config. If dynamic cookies are enabled (ie there exists a schema for cookies), the cookie config is injected into the compiled route without first being sanitised.

Availability of this exploit is generally low, as it requires write access to either the Elysia app's source code (in which case the vulnerability is meaningless) or write access to the cookie config (perhaps where it is assumed to be provisioned by the environment).

However when combined with GHSA-hxj9-33pp-j2cc, this vulnerability allows for a full RCE chain.

Impact - aot enabled (default) - cookie schema passed to route - Cookie config controllable eg. via env

Example of vulnerable code js new Elysia({ cookie: { secrets: ' + console.log('pwned from secrets') + ' }, }) .get("/", () => "hello world", { cookie: t.Cookie({ foo: t.Any(), }), })

POC: https://github.com/sportshead/elysia-poc

Patches Patched by 1.4.17 (https://github.com/elysiajs/elysia/pull/1564)

Reference commit: - https://github.com/elysiajs/elysia/pull/1564/commits/26935bf76ebc43b4a43d48b173fc853de43bb51e - https://github.com/elysiajs/elysia/pull/1564/commits/3af978663e437dccc6c1a2a3aff4b74e1574849e

Workarounds Sanitize cookie-related env input

typescript const overrideUnsafeQuote = (value: string) => // '' + value + '' '' + value.replace(/'/g, '\\').replace(/\${/g, '$\\{') + ''

Elysia is a Typescript framework for request validation, type inference, OpenAPI documentation and client-server communication. Versions 1.4.0 through 1.4.16 contain a prototype pollution vulnerability in mergeDeep after merging results of two standard schema validations with the same key. Due to the ordering of merging, there must be an any type that is set as a standalone guard, to allow for the proto prop to be merged. When combined with GHSA-8vch-m3f4-q8jf this allows for a full RCE by an attacker. This issue is fixed in version 1.4.17. To workaround, remove the proto key from body.