Isn't this yet another duplicate of the plethora of SCP related bugs we've seen in the past?
Why is it marked severity High when it requires a user to already have the power to log in via SSH and perform those commands?

In reply to comment #1:
> Isn't this yet another duplicate of the plethora of SCP related bugs we've
> seen in the past?
> Why is it marked severity High when it requires a user to already have the
> power to log in via SSH and perform those commands?

So, I don't believe it's a duplicate based on the bugs I have searched / looked through prior to the request to try and make sure it was not a dupe. While the affect might be similar to some bugs we have seen before, the root cause here is with the rsync program, which hasn't been covered before from what I saw (at least for this type of bug). Of course, I could be wrong as the duplicate info is based on a quick check.

In regards to the High severity, I agree that having a password makes it so this is less of an issue. I thought that PR:L would cover this as you certainly don't need access to a root account for this to work, just any account permissions. While I agree that in most reasonable cases, anyone with a password would just perform a normal SSH in anyways, my issue is that the program performs these actions at all. Ideally the program would be unable to perform these actions on behalf of the user and sanitize input commands properly. My reasoning came from the view that a program should not introduce a vulnerability or method of executing unintended actions. Perhaps adjusting to PR:H would be more appropriate? Totally open to a discussion on this, I tend to err on the side of caution so if perhaps this is too cautious an approach then lets adjust.

First of all can you provide an example of this injection so I can search for relevant priorart?