chore(deps): update dependency dexto to v1.5.1

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
dexto	patch	1.5.0 → 1.5.1

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 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.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/dexto:1.5.1

📦 Image Reference ghcr.io/uniget-org/tools/dexto:1.5.1

digest	sha256:3cfe5853f0bb1720e3091adb70605c74b8509b65bef40a30d6b7790413592657
vulnerabilities
platform	linux/amd64
size	62 MB
packages	521

diff 7.0.0 (npm) pkg:npm/diff@7.0.0 Inefficient Regular Expression Complexity Affected range <8.0.3 Fixed version 8.0.3 Description Impact Attempting to parse a patch whose filename headers contain the line break characters \r, \u2028, or \u2029 can cause the parsePatch method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory. Applications are therefore likely to be vulnerable to a denial-of-service attack if they call parsePatch with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling parsePatch on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed). The applyPatch method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using parsePatch. Other methods of the library are unaffected. Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch's patch header (also known as its "leading garbage"). A maliciously-crafted patch header of length n can take parsePatch O(n³) time to parse. Patches All vulnerabilities described are fixed in v8.0.3. Workarounds If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of these characters: \r, \u2028, or \u2029. References PR that fixed the bug: kpdecker/jsdiff#649

[github-actions]

Attempting automerge. See https://github.com/uniget-org/tools/actions/runs/21039596664.

[github-actions]

PR is clean and can be merged. See https://github.com/uniget-org/tools/actions/runs/21039596664.