Package Instance

Elysia affected by arbitrary code injection through cookie config
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 Cookie Value Prototype Pollution
### 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

Elysia has a string URL format ReDoS
### 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 | elapsed_ms |
| --- | --- |
| 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 | elapsed_ms |
| --- | --- |
| 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
	)
)
```