Effects like this can happen because the bullet is colliding with something very shortly after spawning - like a piece of your character or gun - or spawning inside another collider. When this happens, the physics engine tries to force the objects apart, which can deflect the bullet off-course.
Using physics layers or
Physics2D.IgnoreCollision methods, you can ensure the bullet can't hit your character, which prevents most of these unexpected deflections.
I notice you're using
Rigidbody2D, which suggests you're making a 2D game. (This is one of those cases where including a screenshot in your question really helps).
In a 2D game, the physics happens in the xy plane. If your camera is looking at the xy plane, then
Camera.main.transform.forward is pointing along the z axis - perpendicular to the plane of physics. The same goes for the transforms of any sprites or quads visible to the camera - their forward / z axis (the blue arrow in the editor's translation gizmo) points "into" the screen, not along it.
So when you tell the bullet to "go forward" in this sense, it's like if I told you not to go up/down/north/south/east/west, but "go ana" or "increase your spissitude" - those aren't directions you can go in your three-dimensional physics world!
This means your velocity assignment could end up being a no-op - adding zero velocity, so the only movement imparted on the bullet comes from collision resolution as described above - or if the forward vector is very slightly tilted relative to the xy plane you might get a small nudge in the direction of the tilt.
In 2D, you usually want to work with left & right vectors or up & down, instead of forward/back (which generally point into / out of the screen)