code16 Sharp CVE-2026-61823

Requires an authenticated Sharp user who has permission to edit an Editor (rich-text) field that uses the affected HTML sanitizer, on a version before 9.22.5. The attacker stores an iframe with a 'srcdoc' attribute containing script; exploitation only fires when another user (typically a higher-privileged admin) views the stored content, so success depends on that victim interaction (UI:R). Limiting factors: valid account plus Editor-field edit privilege (PR:L), a second viewing user, and an unpatched instance; the documented workaround is to strip every iframe 'srcdoc' attribute before storing or rendering Editor content.

This is a genuine but moderate-priority stored XSS (CVSS 7.3, CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N) in code16 Sharp's rich-text Editor field, confirmed by the vendor GitHub advisory (GHSA-qxg3-46rw-79j8) and the fix commit that removes 'srcdoc' from allowed iframe attributes. The signals are internally consistent: network vector but gated by PR:L (attacker needs a valid account with permission to edit an Editor field) and UI:R (a second user must view the poisoned content). No EPSS score, KEV listing, or public exploit is present in the input, so exploitation status is 'no public exploit identified at time of analysis' - this is not a mass-exploitation candidate and there is no SSVC automatable/technical-impact data to weigh. The C:H/I:H rating reflects the worst-case admin-context impact (session hijacking, account takeover, privilege escalation) claimed in the description rather than a demonstrated exploit; because the payload runs in an authenticated admin/back-office UI, that high-impact rating is defensible. Net: a real vulnerability worth patching, especially in multi-user Sharp back offices, but the required authentication and victim interaction make it targeted/insider-flavored rather than a broad internet-facing threat.

A lower-privileged but authenticated Sharp back-office user with edit rights on an Editor field saves content containing '<iframe srcdoc="<script>alert(document.cookie)</script>"></iframe>'; the sanitizer HTML-encodes the srcdoc value but the browser decodes it when rendering the iframe document, so the script executes. When a higher-privileged administrator later opens that record, the JavaScript runs in their session, enabling session/cookie theft, actions on their behalf, or privilege escalation. No public exploit code is identified, though the fix commit's test case includes a working srcdoc payload.