Your design is at odds with reality, and you need to bring the two into alignment.
The thesis of your design seems to be, essentially, that "everything is an entity" and "everything is in one big list" because you can just
update() that whole list. That's fine, up until the point where it isn't, which is the point you've reached now.
Your interface for
Entity is not rich enough to actually express reality: some
Entity implementations require extra information to fully update themselves, information that is not present in
Entity. You can address this in a few ways.
One way is to give
Entity that information; this means storing the target position or target entity in
Entity itself instead of
Goblin, which now let's
Entity have the requisite interface to manage and update the target position. If most subclasses won't use this information, however, this is somewhat wasteful.
What I'd argue is the better way is to simply treat the entities that need special handling (goblins) differently. Store them in a separate
std::vector<Goblin*> so you know everything in that vector is a goblin and can use the goblin-specific APIs. Then you can both
update() them and set their target positions all in a loop.
This avoids complicating the base class with data and methods that aren't universal to all child types. It also gives you a much stronger locality of reference with respect to the update of the goblin instances: you can know when all the goblins start and stop the update work because there's an explicit loop for it, rather than a loop over the big entity "master list" that is potentially processing entity types in an effectively-random order.
This can be a huge win when when you end up having other logic that really wants to depend on the goblin update being "done," as well as for finding places where your work can be data-parallel and benefit from concurrency.
And of course it doesn't involve
dynamic_cast or the stashing of information in well-known globals, as requested.