The Apple Safari web browser contains a JavaScript engine with a rather simple name — JavaScriptCore. However, the engine itself is anything but simple. One common feature within JavaScript interpreters is to have a just-in-time (JIT) engine to increase performance of the executed JavaScript, and JavaScriptCore is no exception. JavaScriptCore takes an interesting approach to this need for speed by supporting multiple tiers of optimization levels; even allowing for switching between them within a single function depending on collected statistics. As with other JIT engines, the optimization strategies employed by Safari’s JIT engine have also resulted in a number of vulnerabilities. The architecture of JavaScriptCore’s JIT engine is to have different tiers based on the number of executions. Thanks to recursion, it is even possible to have a call stack where the same function is represented by the different layers. The downside to applying typical compiler optimizations in order to JIT compile custom user-supplied code is that basic assumptions can be broken. WanderingGlitch will cover the low-level internals of JavaScriptCore, and how the immense complexity can be exploited. He will also details specific JIT vulnerabilities and how Apple chose to patch them. If JavaScript is the assembly language of the web, then the JavaScript engine is the processor. The net result is an exponential increase in the potential for untoward interactions between features of the engine’s code base. Understanding how JavaScriptCore and its JIT engine function reveals the true risk, and a better understanding of the internal aid in finding new bugs and helping secure it.