GitPython 3.1.50 attempts to block unsafe git clone options like --upload-pack (-u) by default unless allow_unsafe_options=True is set. However, the implementation does not properly canonicalize joined short options that take values, such as '-u/path/to/helper'. Git itself accepts '-u<upload-pack>' as equivalent to '--upload-pack=<upload-pack>', executing the helper command. GitPython's check splits multi_options but canonicalizes '-u<value>' to 'u<value>', which does not match the blocked 'u' option, allowing execution of the helper command despite the safety gate. This is a residual bypass of the explicit security boundary in GitPython's clone method. The vulnerability requires an attacker to control the multi_options argument passed to Repo.clone_from and relies on GitPython's default blocking behavior. The issue is confirmed with a local proof of concept that shows the helper script execution despite allow_unsafe_options=False. No patch or official fix is currently documented for this specific bypass in version 3.1.50.

An attacker who can influence the multi_options parameter in GitPython's Repo.clone_from can bypass the default protection that blocks unsafe git clone options. This allows execution of arbitrary local commands via Git's --upload-pack/-u option during a clone operation. This bypass circumvents an explicit security boundary designed to prevent command execution without explicit allowance, potentially leading to local command execution in the context of the application using GitPython. The clone operation itself may fail if the helper exits nonzero, but the command execution side effect occurs, which could be leveraged for malicious purposes.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The suggested remediation is for GitPython to properly parse and canonicalize joined short options that take values (e.g., '-uVALUE' and '-cKEY=VALUE') to their base short option names before checking against the unsafe option set. Until a fix is released, users should avoid passing untrusted input to the multi_options parameter in Repo.clone_from or explicitly set allow_unsafe_options=True only when safe. Monitoring GitPython repository advisories and updates for a fix addressing this joined short option bypass is recommended.