CVE-2022-33098

What it actually does

CVE-2022-33098 is a cross-site scripting vulnerability in Magnolia CMS 6.2.19 affecting the Edit Contact function. The flaw allows attacker-supplied input to be rendered as executable HTML or JavaScript in a victim’s browser. Because the CVSS vector indicates network exploitability, low attack complexity, no attacker privileges required, and required user interaction, exploitation typically depends on a victim opening or viewing content containing the crafted payload. Successful exploitation can allow script execution in the security context of the user’s active Magnolia CMS session, enabling theft of session-related data accessible to JavaScript, unauthorized actions as the victim, page/content manipulation, or redirection to malicious sites.

Why it matters to the business

An attacker could use this flaw to compromise CMS users, especially editors or administrators, and perform actions through their authenticated session. For organizations using Magnolia CMS to manage public-facing or business-critical content, this can result in unauthorized website changes, reputational damage, credential/session exposure, phishing delivery from trusted pages, and potential pivoting into administrative workflows. The issue is not listed in CISA KEV and is not known to be ransomware-associated, but the EPSS score is elevated and exploit code is reported as available, increasing the likelihood of opportunistic exploitation against exposed Magnolia deployments.

How an attack unfolds

An attacker identifies a Magnolia CMS 6.2.19 instance and targets the Edit Contact workflow. They craft an input value containing JavaScript or HTML designed to execute when the vulnerable field is rendered. The attacker then delivers the payload through the vulnerable contact-editing path or by inducing a user to open a crafted link or record that causes the payload to render. When a CMS user views the affected content, the browser executes the attacker-controlled script in the context of the Magnolia CMS origin. From there, the attacker may read data available to the page, abuse the victim’s authenticated session to perform CMS actions, alter content, redirect users, or stage further phishing and credential-harvesting activity.

How to fix it

Upgrade Magnolia CMS to a vendor-supported version that contains the fix for this XSS issue. No exact fixed version was provided in the input, so confirm the appropriate patched release from Magnolia’s official advisories, release notes, or support channels. As compensating controls, restrict access to Magnolia authoring and administration interfaces to trusted networks or VPN users, enforce strong authentication and MFA for CMS accounts, reduce privileges for editors and contact-management users, deploy input validation and output encoding where custom templates or modules render contact data, and consider a restrictive Content Security Policy to reduce the impact of injected scripts. If immediate upgrade is not possible, disable or limit access to the vulnerable Edit Contact function until patched.

How to confirm the fix worked

Confirm the deployed Magnolia CMS version is no longer 6.2.19 or another affected build and is on a vendor-supported patched release. Review release notes or vendor advisories to verify the XSS fix is included. Test the Edit Contact function in a non-production environment using benign XSS validation strings such as an encoded script or harmless event-handler payload and confirm that the payload is encoded, rejected, or rendered inert rather than executed. Validate that CMS administrative interfaces are not broadly exposed to the internet, that session cookies use Secure and HttpOnly where applicable, and that a Content Security Policy is configured to limit inline script execution. Run authenticated application scanning focused on reflected and stored XSS paths in contact-management workflows.

Typical attack path

1. Identify a Magnolia CMS deployment, particularly version 6.2.19.
2. Locate or reach the Edit Contact function that reflects or stores user-controllable input.
3. Create a crafted HTML or JavaScript payload suitable for the vulnerable field or request parameter.
4. Deliver the payload through the vulnerable function or lure a target user into interacting with a crafted record or link.
5. Wait for an authenticated CMS user to view the affected page or edit screen.
6. Execute JavaScript in the victim’s browser under the Magnolia CMS origin.
7. Use the victim’s session context to steal accessible data, perform unauthorized CMS actions, modify content, or redirect the user to attacker-controlled infrastructure.

How to detect it

To determine whether exploitation has already occurred, review Magnolia CMS application logs, web server logs, reverse proxy logs, WAF events, and SIEM telemetry for requests to contact-editing functionality containing script-like input. Focus on suspicious parameters or form submissions with HTML tags, JavaScript schemes, encoded payloads, event handlers, iframe/object/embed tags, or references to external attacker-controlled domains. Correlate any suspicious payload submissions with subsequent authenticated activity by CMS users, especially unusual content edits, new users, privilege changes, template modifications, redirects, unexpected media uploads, or configuration changes. Review CMS audit logs for actions performed shortly after a user viewed or edited contact records. In browser or endpoint telemetry, look for CMS users loading unusual external JavaScript, making unexpected outbound requests after visiting Magnolia administrative pages, or downloading suspicious files. If stored XSS is suspected, inspect contact records and CMS-managed content for injected HTML or JavaScript, including encoded or obfuscated variants.

• <script
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• <iframe
• </iframe>
• <img
• src=x
• alert(
• document.cookie
• document.location
• window.location
• eval(
• atob(
• String.fromCharCode
• %3Cscript
• %3C%2Fscript%3E
• %3Ciframe
• %6a%61%76%61%73%63%72%69%70%74
• Edit Contact

What your security team should do

• Prioritize patching or upgrading Magnolia CMS instances running version 6.2.19 because exploit code is reported as available and EPSS likelihood is elevated.
• Inventory all Magnolia CMS deployments, including authoring, public, staging, and development environments, and identify any exposed administrative or contact-management functions.
• Restrict Magnolia authoring/admin access to trusted IP ranges, VPN, or zero-trust access controls until patched.
• Review CMS user roles and limit high-privilege editor/admin access to users who require it.
• Search application, reverse proxy, WAF, and access logs for XSS payload patterns targeting contact edit endpoints and fields.
• Inspect recent CMS content, contact records, templates, and user-generated fields for unexpected script, iframe, event-handler, or encoded HTML payloads.
• Require re-authentication or rotate sessions for privileged CMS users if exploitation is suspected.
• Deploy or tune WAF rules to detect common XSS payloads, including script tags, JavaScript URLs, event handlers, and encoded variants.
• Implement or tighten Content Security Policy to reduce the impact of any residual XSS.
• Perform post-remediation application testing to confirm payloads are properly encoded or blocked.