A use-after-free bug happens when one part of a program requests a block of memory to be reserved for its own exclusive access, uses that memory for a while, then relinquishes its claim on that memory block…
…only to carry on accessing that memory anyway, even after it’s been reallocated to some other part of the program, or perhaps even to another program entirely.
Imagine that you’re in the middle of a PowerPoint presentation that you’ve checked carefully and rehearsed plentifully, but just before you click through from slide 4 to slide 5, someone who thinks they’re updating slide 5 of their presentation manages to write their new data into your presentation instead. You’d end up blithely presenting someone else’s content as your own, with no inkling of the impending disaster. Even if that sort of thing happened entirely by accident, due to a genuine mistake by a trustworthy colleague, the outcome would probably be annoying, and might even be embarrassing. But if the other person knew perfectly well what they were doing, and how to orchestrate it, and if they timed their “intervention” deliberately and maliciously, the outcome could be disastrous, and perhaps even career limiting. That’s an analogy of the content crisis that use-after-free bugs can cause, often with malware implantation being the unexpected and unwanted side-effect of an exploitable use-after-free hole.