A common approach is that there is a bug in the JavaScript engine (most often a bug in the JIT) which makes it possible for a bit of nasty JS code to start exec

A common approach is that there is a bug in the JavaScript engine (most often a bug in the JIT) which makes it possible for a bit of nasty JS code to start executing arbitrary native code inside the browser tab. This can, for example, involve corrupting the memory of a JavaScript object, gaining read/write access to the heap, and then further corrupting e.g. C++ virtual function tables to redirect control flow execution. This gives the attacker control over the “renderer” process that handles the webpage inside a secured sandbox. So, the attacker has to then exploit the sandbox itself to gain more permissions. The renderer communicates with the parent browser process over IPC, and there are a lot of objects and communications channels between the two. So, a second bug in the browser process can be exploited by the (compromised) renderer process via IPC. Once successful, the attacker has full control over the browser and can do anything the browser can. Sometimes this is enough for the attacker; other times, they might exploit a third bug in the OS kernel to gain root access and thoroughly own your phone.