Package Instance

path-to-regexp contains a ReDoS
### Impact

The regular expression that is vulnerable to backtracking can be generated in versions before 0.1.12 of `path-to-regexp`, originally reported in CVE-2024-45296

### Patches

Upgrade to 0.1.12.

### Workarounds

Avoid using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, you can define the regex used for both parameters and ensure they do not overlap to allow backtracking.

### References

- https://github.com/advisories/GHSA-9wv6-86v2-598j
- https://blakeembrey.com/posts/2024-09-web-redos/

Jinja has a sandbox breakout through indirect reference to format method
An oversight in how the Jinja sandboxed environment detects calls to `str.format` allows an attacker that controls the content of a template to execute arbitrary Python code.

To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.

Jinja's sandbox does catch calls to `str.format` and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's `format` method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Jinja has a sandbox breakout through malicious filenames
A bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of if Jinja's sandbox is used.

To exploit the vulnerability, an attacker needs to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates where the template author can also choose the template filename.

Predictable results in nanoid generation when given non-integer values
When nanoid is called with a fractional value, there were a number of undesirable effects:

1. in browser and non-secure, the code infinite loops on while (size--)
2. in node, the value of poolOffset becomes fractional, causing calls to nanoid to return zeroes until the pool is next filled
3. if the first call in node is a fractional argument, the initial buffer allocation fails with an error

Version 3.3.8 and 5.0.9 are fixed.