You can't get the "right" vector from just a "forward" vector. Any particular "forward" vector could have an infinite number of different legal "up" and "right" vectors.
For example, if I am looking forward along the z axis
forwardVector = vec3(0,0,1), then I could have up be along the y axis
upVector = vec3(0,1,0) and right therefore be along the x axis
rightVector = vec3(1,0,0), or I could have up be along the -y axis
upVector = vec3(0,-1,0) and therefore right would be along the -x axis
rightVector = vec3(-1,0,0). Or I could even have 'up' be along the x axis
upVector = vec3(1,0,0), which would mean that right is along the y axis
rightVector = vec3(0,1,0). And so forth. No one "up" or "right" vector can be considered "correct" if all you have is a forward vector, without imposing some extra constraints on the system.
One common constraint to add to this kind of system is that "up" should be pointing as close as possible to some objective "up" in the scene. Lots of 3D platform games do this, for example. In these, you can calculate your "right" vector by taking the cross product of the forward vector against vec3(0,1,0) (or whatever your world-space 'up' is), and then the cross product of the right vector against the forward vector. And that would work.
But it wouldn't be an arcball, since the camera would always be re-orienting itself so that its local 'up' pointed upward in the world, where arcballs are supposed to maintain their accumulated orientation as you rotate.
For a proper arcball, you need to not be storing the camera position at all; instead, you should just store the camera's orientation. Keep its forward, its up, and its right vectors, and rotate all of them based on the pitch and yaw, and then reconstruct a new camera position based upon the target position and the forward vector. And then you can LookAt using the up vector that you already have!