Error when cloning repos: [fetch-pack: unexpected disconnect while reading sideband packet]

Gitea Usages
1

Hello everyone,

It’s my first time posting here, and I hope my first won’t be a bad one, but I am relatively confused with the current issue I am having and the solutions present there on the internet that I have found as well as here on the forums are not helpful.
So, whenever I try to clone a repository from my gitea instance I can’t since when doing that via ssh i get:
BUG: upload-pack.c:262: packfile_uris requires sideband-all
error:
error: Failed to execute git command
error:
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

And it doesn’t matter if it’s a shallow clone or not, the same thing also happens via https (But the stack-trace there is even more scarce):
fetch-pack: unexpected disconnect while reading sideband packet
fatal: protocol error: bad pack header

I have checked my local git configurations to make sure that the internet connection was not the issue, and tried git protocol v2 as well as other options, i.e. something mentioned here.
My gitea is version 1.27.3 built with go1.26.7-X:jsonv2 : bindata, timetzdata which is in docker container with nginx reverse proxy.
And my client machines where I am trying to pull are MacOS Tahoe 26.6.2 and git 2.50.1 and EndeavourOS with git 2.53.0.

The most confusing part here is that it only doesn’t function on clone, the various repos i have on different machines do work, but the clone is the problem.
If you ever encountered similar issue or have a similar setup and would share the possible solution - I would be very grateful!

Have a nice day!

1 Like
2

yeah that packfile_uris / sideband-all blowup on clone while normal pull still works usually means the server git that gitea shells out to is fighting the clients pack negotiation.

for me id check what git the container actually runs (git --version inside the gitea container) and whether nginx is buffering the git smart-http path. try a clone with GIT_TRACE_PACKET=1 once and also test git -c uploadpack.allowpackuris=false clone ... from the client if your git is new enough.

if https still dies with bad pack header after that, paste the nginx location for / and /v2/ (or gitea path) plus whether proxy_request_buffering / proxy_buffering are on. those two being on have bitten me on big clones behind nginx even when small fetches looked fine.

3

same problem for our server. From Mac, from Linux, from a container created in the swarm where gitea is running. This start something like 30 hours ago.

Still is possible to do `git push`, but not clone, nor pull

4

I had the same symptoms on all repositories:

  • HTTPS clone/fetch: fatal: protocol error: bad pack header or fatal: early EOF / invalid index-pack output

  • SSH clone/fetch failed as well

  • git fsck --full was clean

  • cloning the bare repository locally with file:// worked

  • running git pack-objects manually also worked

  • bypassing the reverse proxy and cloning directly from http://127.0.0.1:3000 still failed

In my case, the root cause was a malicious/suspicious global Git configuration used by Gitea.

Check:

docker exec gitea sh -c 'cat /data/gitea/home/.gitconfig'

I found this unexpected entry:

[uploadpack]
    packObjectsHook = sh /data/gitea/home/p0_5208336a.sh ;#router: completed POST /api/internal/manager/add-logger ...

The referenced script contained:

touch /tmp/g59774_5208336a
id > /tmp/g59774_5208336a.out 2>&1

uploadpack.packObjectsHook replaces the normal git pack-objects command used by git-upload-pack. Therefore every HTTP/SSH clone or fetch invoked this script instead of producing the expected Git pack stream, explaining the bad pack header, early EOF, and invalid index-pack output errors.

The repository data itself was not corrupted.

After preserving the suspicious files for investigation, the corrective action is to remove the malicious Git configuration:

docker exec gitea sh -c '
HOME=/data/gitea/home \
git config --global --unset-all uploadpack.packObjectsHook
'

and disable/remove the referenced script, then restart Gitea.

I would strongly recommend anyone seeing these symptoms to inspect /data/gitea/home/.gitconfig before spending too much time debugging Git protocol versions, reverse proxies, HTTP timeouts, or repository corruption.

Also, this should be treated as a possible security incident, not just a Git configuration problem. The unexpected script and packObjectsHook indicate that something obtained the ability to write files/configuration as the Gitea service account.

If your instance was running a vulnerable Gitea version, also review the recent Gitea RCE advisories and upgrade to a patched release. Do not assume that removing packObjectsHook alone is sufficient remediation.

2 Likes
5

Thanks @DARKNAGAN , this was indeed my issue!
And thanks for providing the steps for mitigating this security incident.
Stay safe everyone!

7

Hello. I found this thread while investigating git push failure. My instance has been compromised at Sep. 10 and from what it seems the attacker (fortunately) only broke the git config in a way @DARKNAGAN described. The payload inside .sh script did not contain anything malicious either besides serving as a proof of work of compromise.

If your instance is compromised simply restoring the config will not help you, keep in mind the attacker already knows your instance’s internal token. You need to rotate everything you can read in /data/gitea/conf/app.ini as well as check all over your repos for recently modified hooks and such. Grep all over your nginx/caddy logs for “add-logger” as well as “refs?service=git-upload-pack”. At that point I am going to take my instance down and spin a new container safely transferring my repos back, but restoring the releases would require me some manual work.