GHSA-8847-338w-5hcj

### Summary Versions of `i18next-fs-backend` prior to 2.6.4 interpolate the caller-supplied `lng` and `ns` values directly into the configured `loadPath` and `addPath` templates with no path-component validation and no sanitisation. When an application exposes the resolved language code to user-controlled input (`?lng=` query parameter, cookie, request header), a crafted value can break out of the intended locale directory. Affected call sites in `lib/index.js`: - `read` (line 38 pre-patch): `const filename = interpolate(loadPath, { lng: language, ns: namespace })` - `removeFile` (line 101 pre-patch): same pattern against `addPath` - `writeFile` (line 127 pre-patch): same pattern against `addPath` for queued missing-key writes The helper `interpolate` in `lib/utils.js` substitutes raw values with no encoding — unlike the `addQueryString` helper in `i18next-http-backend`, there is no equivalent safety for path interpolation. ### Impact - **Arbitrary file read.** With a `loadPath` like `/locales/{{lng}}/{{ns}}.json`, an attacker-controlled `lng = '../../etc'` (and matching `ns`) causes the backend to read a file outside the locale directory. For parsers that tolerate arbitrary content (YAML's freeform text), the file contents surface as a translation resource. - **Arbitrary file overwrite.** `addPath` is interpolated the same way for missing-key writes (the `create()` code path and the debounced writer in `writeFile`). A traversing `lng`/`ns` combination can cause the process to write JSON structures to an unintended filesystem location, potentially overwriting application files if the process user has write access. - **Chain with `.js`/`.ts` eval.** `i18next-fs-backend` supports loading `.js` and `.ts` locale files by `eval`-ing their content (intentional feature, documented as requiring trusted sources). Combining traversal with that path — for example `lng = '../../../app/config'` against `loadPath: '/locales/{{lng}}/{{ns}}.js'` — would cause the backend to *