Jenkins opublikował 2 września duży zestaw advisories. Jednym z ciekawszych dla VM jest CVE-2026-84672 w Microsoft Entra ID Plugin. Plugin przyznawał Jenkins permissions grupom Entra na podstawie object ID (GUID) oraz display name. Problem: display names grup Entra nie są globalnie unikalne. Jeżeli tenant nie ogranicza tworzenia grup, zwykły użytkownik może utworzyć grupę o nazwie identycznej z nazwą uprzywilejowanej grupy — a plugin może przyznać mu jej permissions, nawet jeśli administrator konfigurował grant używając właściwego GUID.
…enableDisplayNameAuthorization=true przywraca stare (insecure) zachowanie.Dlaczego to niebezpieczny failure mode?
Administrator zrobił pozornie wszystko dobrze — wybrał konkretny obiekt Entra o unikalnym ID. Ale downstream integration zachowała dodatkową, słabszą reprezentację tożsamości (object_id: unique obok display_name: not unique) i używała obu jako równoważnych podczas authorization. To security regression w warstwie integracyjnej, nie w Entra ID.
Cross-system affectedness
CVE siedzi w pluginie Jenkins, ale exploitation zależy od konfiguracji Microsoft Entra ID: jeśli zwykli użytkownicy nie mogą tworzyć grup, jeden z kluczowych prerequisites znika. Finding powinien zawierać: plugin affected? can tenant members create groups? privileged Jenkins grants assigned to Entra groups? duplicate display names possible/present? To oznacza, że pojedynczy owner findingu może nie wystarczyć — remediation wymaga współpracy Jenkins owner, IAM/Entra team i security engineering.
Fix może zmienić dostęp — i przywrócić podatność
Plugin 711.v34046f788fd7 przestaje przyznawać uprawnienia po display name i używa wyłącznie GUID. Jenkins ostrzega jednak, że administratorzy, którzy wcześniej polegali na nazwach grup, mogą po aktualizacji stracić dostęp. Istnieje system property przywracające stare zachowanie (…ObjId2FullSidMap.enableDisplayNameAuthorization=true) — ale Jenkins wprost ostrzega, że jest to insecure i powinno służyć tylko jako krótkotrwała pomoc migracyjna. To kapitalny przypadek dla risk acceptance: presja „po patchu część zespołów straciła dostęp, włączmy compatibility flag” przywraca podatny model authorization. VM powinien stworzyć stan:
Sam version scanner mógłby błędnie pokazać „fixed”.
Wniosek
CVE-2026-84672 pokazuje, że remediation nie zawsze kończy się wraz z instalacją fixed pluginu. Jeżeli compatibility setting przywraca podatną semantykę, wersja jest naprawiona, ale środowisko nadal zachowuje vulnerable behavior. To jeden z najlepszych przykładów, dlaczego verification musi sprawdzać security property, a nie tylko numer wersji.
Powiązane na blogu
- Devtron: PR:L do platform takeover — authz/tożsamość i credential-mediated escalation
- Keycloak: CVE tylko przy niebezpiecznej konfiguracji — status zależny od konfiguracji
Źródła
- Jenkins — Security Advisory 2026-09-02 (CVE-2026-84672) — jenkins.io
Nota redakcyjna: stan informacji 3 września 2026. CVE-2026-84672 (Jenkins Microsoft Entra ID Plugin): autoryzacja po nieunikalnym display name obok GUID; fix 711.v34046f788fd7 używa wyłącznie GUID, ale property enableDisplayNameAuthorization=true przywraca insecure zachowanie. Artykuł koncentruje się na patched-binary vs effective-remediation i cross-system affectedness.