CVE-2026-41888

W trybie pull-through cache narzędzia Distribution (przed wersją 3.1.0) punkty końcowe uwierzytelniania tokenami są odkrywane przez parsowanie wyzwań WWW-Authenticate zwracanych przez skonfigurowany rejestr nadrzędny. Adres URL realm z wyzwania bearer jest używany bez weryfikacji, czy odpowiada hostowi rejestru nadrzędnego, co pozwala atakującemu kontrolującemu rejestr nadrzędny (lub znajdującemu się na pozycji MitM) na spowodowanie wysłania skonfigurowanych poświadczeń rejestru nadrzędnego przez basic auth do adresu URL realm kontrolowanego przez atakującego. Podatność naprawiono w wersji 3.1.0.

W bibliotece Distribution (registry/client) w wersjach przed 3.1.2 metoda Get() odczytuje manifest zwrócony dla żądania przypiętego do digestu i przekazuje go do distribution.UnmarshalManifest bez weryfikacji skrótu względem żądanego digestu. Umożliwia to złośliwej lub przechwyconej odpowiedzi rejestru podstawienie treści manifestu wybranej przez atakującego, nawet gdy nagłówek Docker-Content-Digest wskazuje żądaną wartość. Wbudowany proxy pull-through może dodatkowo buforować i ponownie serwować podstawiony manifest. Problem naprawiono w wersji 3.1.2.

W Distribution (narzędzie do pakowania i dystrybucji kontenerów) przed wersją 3.1.0, gdy włączone są opcje storage.cache.blobdescriptor: redis i storage.delete.enabled: true, usunięcie bloba z repozytorium a nie usuwa całkowicie wpisów w pamięci podręcznej Redis. Po późniejszym odczycie z repozytorium b, usunięty blob staje się ponownie dostępny w repozytorium a.