CVE-2023-23074

What it actually does

This is a cross-site scripting flaw in a web application component that handles embedded video content in a language-related feature. Because attacker-controlled markup or script can be accepted and later rendered in a user’s browser without sufficient sanitization or output encoding, JavaScript may execute in the security context of the vulnerable application. The CVSS vector indicates network exploitability, low attack complexity, no privileges required, but user interaction is required; successful exploitation can affect confidentiality and integrity by allowing session-token theft, unauthorized actions as the victim, phishing overlays, or manipulation of displayed application data. The provided affected-product metadata identifies gentoo/soko with a fix at commit d3516dc8fcefff629c5b196b8a4d4c4a21b6bc40, while the description references Zoho ManageEngine ServiceDesk Plus 14; teams should validate applicability against their actual product inventory and vendor advisories.

Why it matters to the business

An attacker who gets a user to view maliciously crafted content in the affected application may be able to impersonate that user inside the application, read exposed data, or perform actions the user is authorized to perform. For a service desk or package-index style application, this can lead to ticket or account data exposure, unauthorized changes, credential capture, and loss of trust in the portal. Although it is not listed in CISA KEV and is not flagged as ransomware-used, the EPSS score is high, and the issue has been public for several years, so internet-facing or broadly accessible deployments should be treated as higher priority than the moderate CVSS score alone suggests.

How an attack unfolds

An attacker identifies a vulnerable page or workflow that accepts video embed content in the language component. They submit or cause the application to process a crafted payload containing executable JavaScript, commonly through malformed HTML, event handlers, script URLs, or embedded media tags. If the application stores or reflects that payload and later renders it without safe encoding, a targeted user only needs to open the affected page or view the malicious content. The victim’s browser then executes the attacker’s script as if it came from the trusted application. From there, the attacker can harvest accessible page data, steal session material if not protected by browser controls, perform same-origin requests as the victim, alter visible content, or redirect the user to credential-harvesting pages. Public exploit maturity is listed as none, but the combination of a simple attack pattern and high EPSS means opportunistic probing should be expected.

How to fix it

Apply the vendor fix for the affected software. For gentoo/soko deployments, update to a version that includes commit d3516dc8fcefff629c5b196b8a4d4c4a21b6bc40 or later. Where Zoho ManageEngine ServiceDesk Plus 14 is in scope, confirm the exact affected build with Zoho/ManageEngine advisories and upgrade to a fixed or current supported build. As defense in depth, ensure all user-supplied content in language, rich-text, and media-embed features is sanitized with an allowlist HTML sanitizer; encode output according to context; disallow JavaScript URLs and unsafe event attributes; restrict iframe/embed sources to trusted domains; and deploy a restrictive Content Security Policy. If immediate patching is not possible, disable or restrict video embedding and rich HTML input in the affected component, limit access to trusted users, and monitor for suspicious payload submissions.

How to confirm the fix worked

Confirm the deployed code or package version includes the fixed commit d3516dc8fcefff629c5b196b8a4d4c4a21b6bc40 where gentoo/soko is applicable, or confirm the relevant vendor-fixed build for ManageEngine ServiceDesk Plus if that product is present. In a non-production environment, attempt to submit harmless XSS canary payloads such as an image tag with an onerror handler or a javascript: URL in the video embed/language workflow and verify the payload is rejected, neutralized, or rendered as inert text. Review response HTML to ensure dangerous attributes, script tags, and untrusted embeds are removed or encoded. Validate that CSP headers block inline script execution and untrusted frame/script sources. Finally, scan externally reachable instances and confirm the vulnerable feature is not exposed without appropriate access control.

Typical attack path

1. Recon the exposed application and identify pages or parameters that process language settings, embedded videos, rich text, or media embed markup.
2. Craft an XSS payload using script tags, JavaScript URLs, HTML event handlers, SVG/iframe/video/embed tags, or malformed media embed syntax.
3. Submit the payload through the vulnerable component or lure a user into loading a URL that reflects the payload.
4. Wait for an authenticated user or administrator to view the affected content.
5. Execute JavaScript in the victim’s browser under the vulnerable application’s origin.
6. Use the victim’s browser context to read accessible data, issue unauthorized requests, alter page content, redirect the user, or capture credentials/session artifacts.
7. Cover tracks by removing the malicious content where possible or rotating payload infrastructure.

How to detect it

To determine whether exploitation already occurred, review application access logs, reverse proxy logs, WAF events, and audit logs for submissions containing script-like payloads in fields or URLs related to language settings, localization, rich text, video embedding, or media embedding. Look for encoded variants as well as plain HTML, including percent-encoded angle brackets, JavaScript URLs, event-handler attributes, SVG payloads, iframe/object/embed tags, and references to external attacker-controlled domains. Inspect stored content records or exported application data for suspicious HTML in user-editable language or media fields. Correlate suspicious submissions with subsequent user sessions that viewed the content, unexpected administrative actions, password or email changes, API token creation, unusual ticket/content modifications, or outbound browser requests to unfamiliar domains. Because XSS often leaves no server-side code-execution artifacts, focus on malicious input, victim page views, abnormal account activity, and WAF/browser telemetry rather than host process indicators.

• <script
• %3Cscript
• </script>
• %3C%2Fscript%3E
• javascript:
• java%0ascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• <iframe
• %3Ciframe
• <svg
• %3Csvg
• <img
• %3Cimg
• <video
• %3Cvideo
• <embed
• %3Cembed
• <object
• %3Cobject
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• new Image()
• String.fromCharCode
• alert(
• prompt(
• confirm(
• data:text/html
• srcdoc=
• autofocus onfocus=
• xlink:href=

What your security team should do

• Prioritize asset inventory reconciliation because the supplied metadata references both a Zoho ManageEngine component and gentoo/soko; determine which, if either, exists in the environment before closing the finding.
• Patch or upgrade affected deployments, using commit d3516dc8fcefff629c5b196b8a4d4c4a21b6bc40 or later for gentoo/soko and the vendor-fixed build for ManageEngine ServiceDesk Plus if applicable.
• If patching is delayed, disable or restrict video embedding, rich HTML input, and language-component editing to trusted administrators only.
• Search web, application, reverse proxy, and WAF logs for XSS payload patterns submitted to language, video, embed, rich-text, or localization endpoints.
• Review stored application content for malicious HTML, script, iframe, video, object, embed, SVG, and event-handler attributes.
• Enable or tune WAF rules for reflected and stored XSS payloads, but do not rely on WAF controls as the primary fix.
• Harden browser-side controls with HttpOnly and SameSite cookies, anti-CSRF protections, and a restrictive Content Security Policy.
• If exploitation is suspected, invalidate active sessions, rotate affected credentials or API tokens, and review privileged user activity performed after the suspected exposure window.