Reflected XSS in CKEditor and Angular enables browser-side code execution

A reflected cross-site scripting (XSS) vulnerability in CKeditor v46.1.0 & Angular v18.0.0 allows attackers to execute arbitrary code in the context of a user's browser via injecting a crafted payload.

• CKEditor 5: The normalized record marks version 46.1.0 as affected.
• Angular: The normalized record marks version 18.0.0 as affected.
• No broader affected range or fixed release is supplied in the record. The GitHub Advisory Database also lists affected and patched versions as unknown.
• Red Hat Product Security states that vulnerable code is not present in currently supported Red Hat products. That conclusion is limited to Red Hat's product scope and does not change the CKEditor and Angular exposure identified in this record.

The flaw is a CWE-79 issue in which attacker-controlled data is reflected into web page output without being properly neutralized. A crafted payload can cause arbitrary code to execute in the context of a user's browser. The record supports network reachability, no required privileges, low attack complexity, and required user interaction. It does not identify the request parameter, endpoint, HTML sink, rendering path, or configuration responsible for the behavior, so those implementation details remain unknown.

• The vulnerability is reachable over the network.
• The record states that exploitation does not require authentication or privileges, has low complexity, and requires user interaction.
• The supplied record marks a public exploit as available, and the returned CISA ADP enrichment classifies the exploitation status as proof-of-concept.
• The reviewed sources do not name a campaign, victim, or specific confirmed in-the-wild incident. That does not establish that exploitation has not occurred outside the documented evidence.

The vulnerability can result in arbitrary JavaScript execution in a user's browser within the affected application's context. The described impact is limited to confidentiality and integrity, with no direct availability impact established; the attacker does not need privileges but the user must interact. Real-world consequences may include reading data accessible to the page or performing actions in the user's session, depending on application permissions, browser controls, and other defenses. The record does not establish automatic privilege escalation or a change of security scope.

• A user may execute attacker-controlled code in the context of the affected web application.
• Depending on the user's permissions and the data available to the page, possible consequences include reading some accessible data, performing actions as the user, or modifying content within the browser session.
• Because user interaction is required, operational risk depends on whether an attacker can persuade users to open a link, load content, or submit a request containing the malicious input.
• The issue may require investigation, session or content cleanup, and review of frontend functions that use reflected data. The record does not confirm a data breach or a specific incident.

1. Identify deployments using CKEditor 5 46.1.0 or Angular 18.0.0 and prioritize them for vulnerability handling.
2. No confirmed fixed release or solution is provided in the record. Contact the maintainer or vendor for a supported update and remediation guidance.
3. Do not infer that a CKEditor or Angular release is a fix merely because the release exists in release notes.
4. While waiting for confirmed guidance, assess routes that reflect input into HTML and apply context-appropriate output encoding or sanitization at the point where data enters the page. This is general risk reduction, not a vendor-confirmed workaround.
5. Retest affected functions after updating or changing input handling, especially flows that users can reach through links or externally supplied content.

• Inventory dependency manifests, lockfiles, built artifacts, and frontend bundles to determine whether CKEditor 5 and Angular are deployed.
• Compare the versions actually built and served with the affected versions in the record rather than relying only on development-environment versions.
• Identify routes or functions that place request data into reflected HTML, without assuming a specific endpoint because the record does not provide one.
• In a test environment, verify whether input is reflected into the HTML response without context-appropriate encoding. Use non-executable markers rather than a malicious payload.
• Review application, reverse-proxy, and WAF telemetry for requests containing markup or unusual strings in parameters that are reflected. Treat this as precautionary monitoring, not as a confirmed indicator for this vulnerability.