A newly discovered cross-site scripting (XSS) vulnerability in Safari highlights a critical flaw in the browser’s TypeError exception handling mechanism. Identified by security researcher during his exploration of payload concealment techniques, the vulnerability enables the execution of arbitrary JavaScript code through improperly escaped quotes within error messages. When a developer attempts to instantiate a string with mixed quotes using the new operator (e.g., new 'foo"bar'), Safari throws a TypeError. However, the error message fails to escape embedded double quotes correctly, resulting in malformed strings such as "foo"bar" is not a constructor, which can be manipulated to break out of the intended string boundaries.

This malformed error output creates a novel attack vector, as the mishandling of quote characters in TypeError messages allows attackers to inject executable JavaScript code directly into the error message. Safari’s behavior of converting single quotes to double quotes without proper escaping introduces an untrusted input scenario within the browser’s internal error-handling flow. Since type errors do not halt JavaScript execution like syntax errors do, they present an opportunity for code execution to proceed uninterrupted, even after the generation of the error, forming a reliable exploit channel for attackers.

According to the Researcher, the attack technique is further advanced by leveraging JavaScript’s global onerror event handler. By assigning onerror=eval, attackers can ensure that any uncaught exceptions are passed directly to the eval() function. This results in the error message containing injected JavaScript code being interpreted and executed. For example, the payload new 'foo'-alert(1)//' creates an error message with embedded script ("foo"-alert(1)//" is not a constructor), which is treated as valid JavaScript when evaluated. In this context, the initial quote ends the string, the alert(1) executes, and the comment neutralizes the remaining message, demonstrating a fully functioning XSS exploit.

This vulnerability is particularly severe because it bypasses traditional script injection defenses and exploits the browser’s native error infrastructure—an area typically trusted by developers. It underscores the need for strict input validation, strong content security policies, and heightened scrutiny of how special characters are handled in browser error messages. Additionally, the research reveals that techniques such as using window.name for payload delivery, although limited by Safari’s behavior, can still be used with creative workarounds. Browser vendors must take immediate action to sanitize error messages properly, as even minor implementation oversights can introduce critical security risks in foundational browser features.