Ново изследване показва, че хешът на подписан Git коммит не е уникалното име, което голяма част от софтуерния свят приема, че е. При всеки подписан коммит, някой без подписващия ключ може да създаде втори коммит със същите файлове, автор и дата и валиден подпис, а GitHub все още да поставя печат „Verified“ (Потвърдено).

Всичко, което проверяващият би инспектирал, съвпада. Хешът на коммита обаче – не. Това е от значение, тъй като много системи третират потвърдения хеш на коммит като постоянно, уникално име за неговото съдържание.

Ето конкретния сценарий за срив: блокирате зловреден коммит по неговия хеш, а нападателят може да изпрати (push) отново същото съдържание под нов, все още потвърден („Verified“) хеш, който вашият списък за блокиране никога не е виждал. Дедупликацията, регистрационните файлове за произход и записите за възпроизводими компилации, които разчитат на хеша, наследяват същата уязвимост.

Компрометирано или враждебно огледално копие (mirror) може да предостави на потребителите, които клонират, валидно подписани коммити, чиито хешове се различават от тези в каноничното хранилище.

Това обаче не е начин за прокарване на различен код през проверка на подпис. Файловете са идентични във всяко копие, така че фиксиран от вас хеш все още изтегля точно съдържанието, което очаквате, или се проваля.

Няма издаден CVE код или съвети от доставчици, както и нищо за промяна във вашето собствено хранилище: недостатъкът е в това как платформата за съвместна разработка определя какво означава „Verified“, а корекцията трябва да бъде приложена от страната на платформата.

Работата е дело на Джейкъб Гинесин, докторант в университета Карнеги Мелон и криптографски одитор в Cure53. Неговият документ от пет страници, публикуван в arXiv на 2 юли, идва с публичен инструмент, който изпълнява и трите атаки, плюс две демонстрационни хранилища, където променените коммити все още се показват като „Verified“ в GitHub.

Тъй като всеки коммит посочва своя родител по хеш, промяната на един коммит налага нови хешове за коммитите над него. Инструментът пренаписва тази верига, за да я запази съвместима. Подписаният наследник обаче губи своята значка в момента, в който се промени указателят към неговия родител. Гинесин нарича този ефект „hash chain malleability“ (ковкост на хеш веригата).

Причината е ковкостта на подписа (signature malleability). Хешът на коммита се изчислява върху всичко в него, включително суровите байтове на подписа в неговия хедър. Много подписи могат да бъдат пренаписани в различна, но все пак валидна форма, и промяната на тези байтове променя хеша, без да се засяга нито един ред код.

Трите метода обхващат всяка GPG схема, която GitHub проверява, плюс S/MIME:

  • ECDSA ключове: обръщане на подписа с класическа алгебра на елиптични криви (превръщане на стойността s в n - s). И двете форми са валидни. Това преминава локална проверка с git verify-commit и получава значка в GitHub.
  • RSA и EdDSA ключове: добавяне на допълнително, игнорирано поле към нехешираната секция на подписа – частта, която подписът умишлено не покрива. Подписът все още се проверява успешно, но байтовете на коммита и неговият хеш се променят. Локалната система и GitHub приемат промяната.
  • S/MIME (X.509) ключове: пренаписване на поле за дължина в DER структурата на подписа в по-дълга, нестандартна форма. Стриктна локална проверка (чрез gpgsm) я отхвърля, но GitHub все още я маркира като „Verified“.

След това GitHub записва статус „Verified“ за всеки хеш на коммит и не го проверява отново, така че коммитът остава потвърден дори след като неговият подписващ ключ бъде оттеглен. Ако изпратите оригинален коммит и неговия близнак в два клона, изгледът за сравнение на GitHub ги третира като разминаващи се истории, въпреки идентичните файлове.

Основният трик е стар. Биткойн се бореше с абсолютно същата ECDSA симетрия преди години, когато всеки можеше да обърне стойността на s в подписа на транзакция и да промени ID-то на транзакцията без ключа на собственика. Корекцията беше да се приема само формата „low-S“, а по-късно подписите да се изнесат извън ID-то с SegWit.

Корекциите в документа съвпадат с това: канонизирайте кодирането, преди да се доверите на хеша. Известен урок, а не екзотична нова криптография.

Документът също така свързва това с неотдавнашните отвличания на тагове в GitHub Actions – атаките срещу tj-actions/changed-files през 2025 г. и trivy-action през 2026 г. След тях съветът беше прост: реферирайте към пълен хеш на коммит, а не към подвижен таг. Този съвет все още е в сила.

Реферирането по конкретен хеш спря тези атаки и това изследване не променя това. Неговата цел е по-тясна. В случая с Trivy, зловредните коммити се открояваха, защото не можеха да бъдат валидно подписани. Това е предупреждение да не се разчита твърде много на този белег: валидният подпис доказва кой е подписал коммита, но не прави хеша на коммита уникално име за това, което съдържа.

И така, кой трябва да предприеме нещо? Не и разработчикът, който фиксира Action или модул; фиксираният хеш все още извлича правилния код. Работата е за платформите за съвместна разработка (forges). Документът казва, че те трябва да канонизират подписите, преди да им се доверят.

Инструментите, които блокират, дедуплицират или записват произхода по хеш на коммит, трябва да направят същото, като първо проверяват и канонизират, вместо да се доверяват на суровия хеш на подписан обект, който нападателят може да прекодира.