{"id":184239,"date":"2026-11-12T11:41:56","date_gmt":"2026-11-12T09:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/uyazvimost-v-git-dopuskayushhaya-vypolnenie-koda-pri-klonirovanii-iz-vredonosnogo-git-repozitoriya"},"modified":"2026-11-12T11:42:03","modified_gmt":"2026-11-12T09:42:03","slug":"git-vulnerability-allows-code-execution-when-cloning-a-malicious-git-repository","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/git-vulnerability-allows-code-execution-when-cloning-a-malicious-git-repository","title":{"rendered":"Vulnerability in Git allowing code execution when cloning from a malicious Git repository","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Opublikowano poprawki w rozproszonej systemie zarz\u0105dzania kodem \u017ar\u00f3d\u0142owym Git 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 i 2.50.2, w kt\u00f3rych usuni\u0119to 6 luk w zabezpieczeniach. Najbardziej krytyczna luka (CVE-2026-111760) umo\u017cliwia wykonanie kodu przy u\u017cyciu polecenia \u201egit clone\u201d w trybie \u201e--recurse-submodules\u201d z repozytoriami kontrolowanymi przez atakuj\u0105cego.<\/p>\n
Problem wynika z tego, \u017ce d\u0142ugo\u015b\u0107 wpisu z nazw\u0105 w indeksie jest obliczana przy u\u017cyciu 32-bitowego typu ca\u0142kowitego. Przy przekazywaniu bardzo d\u0142ugiej nazwy w postaci \u201e.git\/...\u201d, wyst\u0119puje przepelnienie ca\u0142kowite i atakuj\u0105cy mo\u017ce uzyska\u0107 d\u0142ugo\u015b\u0107 r\u00f3wn\u0105 4 bajtom. W rezultacie, przy sprawdzaniu warto\u015bci u\u017cywane s\u0105 rzeczywiste dane, a podczas wykonywania operacji u\u017cywana jest skr\u00f3cona wersja \u201e.git\u201d, co pozwala atakuj\u0105cemu na zast\u0105pienie pliku \u201e.git\u201d w submodule symbolicznym linkiem wskazuj\u0105cym na katalog z ustawieniami i hookami.<\/p>\n
Inne podatno\u015bci:<\/p>\n
\n
CVE-2026-113408 \u2014 wyj\u015bcie poza katalog refs\/ poprzez przekazanie jako ga\u0142\u0119zi HEAD symbolicznego linku o warto\u015bci \u201erefs\/heads\/..\/..\/.. \/TARGET\u201d podczas klonowania pustego repozytorium protoko\u0142em Git v2. Przy p\u00f3\u017aniejszym wykonywaniu \u201egit commit\u201d zostanie utworzony plik TARGET w g\u0142\u00f3wnym katalogu repozytorium, co mo\u017cna wykorzysta\u0107 do nadpisywania plik\u00f3w w repozytorium i organizacji wykonania kodu.\n
CVE-2026-114467 \u2014 przepe\u0142nienie stosu podczas usuwania podpis\u00f3w GPG, co potencjalnie mo\u017ce prowadzi\u0107 do wykonania dowolnego kodu. Problem wynika z tego, \u017ce funkcja remove_signature() przechowuje pozycje podpis\u00f3w w sta\u0142ej tablicy, zaprojektowanej maksymalnie na dwa podpisy. Przy przekazywaniu tagu z trzema lub wi\u0119ksz\u0105 liczb\u0105 podpis\u00f3w, dane s\u0105 przechowywane poza tablic\u0105.\n
CVE-2026-114469 \u2014 podczas sprawdzania ogranicze\u0144 rozmiaru binarnych \u0142at, brane by\u0142y pod uwag\u0119 dane przed dekompresj\u0105, co prowadzi\u0142o do odczytu zawarto\u015bci z obszaru poza granicami bufora.\n
CVE-2026-105437 \u2014 uszkodzenie pami\u0119ci podczas wykonywania du\u017cych operacji scalania z powodu nagromadzenia rozmiaru wyniku w polu typu int. W konfiguracji GitLab luka ta mo\u017ce by\u0107 wykorzystywana do wykonania kodu (problem zosta\u0142 zablokowany w GitLab 19.5.4).\n
CVE-2026-114466 \u2014 nadpisanie dowolnych plik\u00f3w w FS przy u\u017cyciu polecenia \u201egit fast-import\u201d z powodu niepe\u0142nego usuni\u0119cia luki CVE-2019-1348.\n<\/ul>\n