File-history restore now rejects bad session ids instead of copying backups anywhere.
What's wrong with this entry?
Restoring from file history now validates the target session id before copying backups. An invalid id logs a warning and aborts the copy, so a crafted id cannot steer backup files into a directory of someone else's choosing.
"FileHistory: refusing to copy backups on restore (invalid target session id)"
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.