🚨 [security] Update svelte 5.53.0 → 5.55.7 (minor)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ svelte (5.53.0 → 5.55.7) · Repo · Changelog

Security Advisories 🚨

🚨 Svelte SSR vulnerable to cross-site scripting via spread attributes

When using spread syntax to render attributes from untrusted data, event handler properties are included in the rendered HTML output. If an application spreads user-controlled or external data as element attributes, an attacker can inject malicious event handlers that execute in victims' browsers. Note that this vulnerability only triggers if the user's browser has JavaScript enabled but Svelte's hydration mechanism does not reach the vulnerable element before the event fires.

This is similar to but different from CVE-2026-27121.

🚨 Svelte: ReDoS in `` Tag Validation

An internal regex in the Svelte runtime can take exponential time to test in <svelte:element this={tag}></svelte:element>. You are only vulnerable to this if you allow tags of unconstrained length. If your application only allows a predetermined list of tags or trims their length before passing them to svelte:element, you are safe.

🚨 Svelte Vulnerable to XSS via DOM Clobbering of Internal Framework State

Svelte was vulnerable to DOM clobbering of its internal framework state on elements, potentially leading to XSS attacks.

You are vulnerable if all of the following is true:

• you are using attribute spreading on a form element
• you are using attribute spreading or allow a dynamic value for the name attribute on an input or button element within that form
• both of these are simultaneously user-controllable

<form {...spread1}>
  <input {...spread2}>
</form>

🚨 Svelte: SSR XSS via Insecure Promise Serialization in hydratable

Contents of hydratable promises were not properly stringified, potentially leading to an XSS exploit. You are vulnerable if all of the following is true:

• you are using hydratable (an experimental feature at the time of this report)
• you are passing attacker-controlled input such that a synchronous value is hydrated, then a promise value, e.g. hydratable('someKey', () => [synchronousValue, promiseValue])

🚨 Svelte vulnerable to XSS during SSR with contenteditable `bind:innerText` and `bind:textContent`

The contents of bind:innerText and bind:textContent on contenteditable elements were not properly escaped. This could enable HTML injection and Cross-site Scripting (XSS) if rendering untrusted data as the binding's initial value on the server.

🚨 Svelte: XSS via HTML Comment Injection in SSR Error Boundary Hydration Markers

Errors from transformError were not correctly escaped prior to being embedded in the HTML output, causing potential HTML injection and XSS if attacker-controlled content is returned from transformError.

Release Notes

Too many releases to show here. View the full release notes.

↗️ devalue (indirect, 5.6.3 → 5.8.1) · Repo · Changelog

Security Advisories 🚨

🚨 Svelte devalue: DoS via sparse array deserialization

devalue.parse could, due to quirks in some JavaScript engines, be convinced to allocate much more memory than was needed when deserializing sparse arrays, leading to excessive memory consumption.

🚨 devalue has prototype pollution in devalue.parse and devalue.unflatten

In devalue v5.6.3, devalue.parse and devalue.unflatten were susceptible to prototype pollution via maliciously crafted payloads. Successful exploitation could lead to Denial of Service (DoS) or type confusion.

🚨 Sveltejs devalue's `devalue.parse` and `devalue.unflatten` emit objects with `__proto__` own properties

In some circumstances, devalue.parse and devalue.unflatten could emit objects with __proto__ own properties. This in and of itself is not a security vulnerability (and is possible with, for example, JSON.parse as well), but it can result in prototype injection if downstream code handles it incorrectly:

const result = devalue.parse(/* input creating an object with a __proto__ property */);
const target = {};
Object.assign(target, result); // target's prototype is now polluted

Release Notes

5.8.0

Minor Changes

• c5115b0: feat: add stringifyAsync for async serialization

5.7.1

Patch Changes

• 8becc7c: fix: handle regexes consistently in uneval's value and reference formats

5.7.0

Minor Changes

• df2e284: feat: use native alternatives to encode/decode base64
• 498656e: feat: add DataView support
• a210130: feat: whitelist Float16Array
• df2e284: feat: simplify TypedArray slices

Patch Changes

• 5590634: fix: get uneval type handling up to parity with stringify
• 57f73fc: fix: correctly support boxed bigints and sentinel values

5.6.4

Patch Changes

• 87c1f3c: fix: reject __proto__ keys in malformed Object wrapper payloads

  This validates the "Object" parse path and throws when the wrapped value has an own __proto__ key.

• 40f1db1: fix: ensure sparse array indices are integers

• 87c1f3c: fix: disallow __proto__ keys in null-prototype object parsing

  This disallows __proto__ keys in the "null" parse path so null-prototype object hydration cannot carry that key through parse/unflatten.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 19 commits:

• Version Packages (#152)
• Merge commit from fork
• Version Packages (#151)
• feat: `stringifyAsync` (#150)
• docs: update README to reflect serialization stability non-goal (#147)
• Version Packages (#146)
• fix: handle regexes consistently in uneval's value and reference formats (#145)
• Version Packages (#144)
• DataView support (#143)
• Improve platform types support (#142)
• fix: support boxed `bigint`s and sentinel values (#141)
• Add prettier configuration (#140)
• feat: whitelist `Float16Array` (#137)
• feat: use native alternatives to encode/decode base64 (#136)
• chore: add simple benchmarks (#135)
• fix: rename test file so uvu picks it up (#134)
• Version Packages (#133)
• Merge commit from fork
• Merge commit from fork

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
ask-hadith	Ready	Preview, Comment	May 14, 2026 10:11pm

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}