CVE-2026-100860
ŚrednieCVSS 5.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 1 - wyżej niż 1% wszystkich znanych CVE
Streszczenie
heym przed wersją 0.0.105 nie uwzględnia wyniku wyszukiwania autoryzacji poświadczeń w węźle Redis. Gdy _get_accessible_credential zwraca None, węzeł traktuje to jako pustą konfigurację i łączy się z localhost:6379 bez hasła, wykonując żądaną operację. Uwierzytelniony autor przepływu pracy, podając identyfikator poświadczenia, którego nie posiada lub które zostało usunięte, uzyskuje połączenie odczytu/zapisu z Redisem na interfejsie loopback.
Ocena ryzyka
Nieautoryzowany dostęp do Redis może prowadzić do odczytu lub modyfikacji danych, a w niektórych wdrożeniach do eskalacji uprawnień. W standardowym docker-compose.yml brak Redis, więc błąd może objawiać się jako mylący błąd połączenia.
Rekomendacja
Zaktualizuj heym do wersji 0.0.105 lub nowszej. Dodatkowo upewnij się, że węzeł Redis nie jest dostępny na interfejsie loopback bez uwierzytelnienia.
Inne podatności w heym
Zobacz wszystkie- CVE-2026-55376Wysokie
Podatność w Heym przed wersją 0.0.40 pozwala uwierzytelnionemu użytkownikowi, który może tworzyć lub edytować workflow z niestandardowym narzędziem Python, na obejście sandboxa opartego na czarnej liście. Biblioteki standardowe Pythona udostępniają funkcje systemowe, które przechodzą walidację, a narzędzie jest wykonywane przez exec(), umożliwiając wykonywanie poleceń i operacji na plikach jako użytkownik aplikacji backendowej. Problem naprawiono w wersji 0.0.40.
- CVE-2026-109362Średnie
Heym w wersji v0.0.5 przed v0.0.113 zawiera podatność związaną z nieskuteczną kontrolą dostępu, która umożliwia byłym współpracownikom dalsze wykonywanie przepływów pracy JWT poprzez ponowne użycie tokenów workflow:execute o zawężonym zakresie po usunięciu udostępnienia. Atakujący może wygenerować token z TTL do 10 lat, którego właściciel nie może wylistować ani cofnąć, i wielokrotnie uruchamiać przepływ pracy, zużywając wspólne poświadczenia.
- CVE-2026-105396Średnie
Heym przed wersją v0.0.112 zawiera podatność na wyciek tokenów w funkcji build_public_base_url(), która umożliwia nieuwierzytelnionym atakującym przekierowanie linków przeglądu HITL poprzez sfałszowanie nagłówków Origin lub X-Forwarded-Host. Atakujący mogą wywołać anonimowe przepływy pracy ze sfałszowanymi nagłówkami, aby powiadomienia recenzentów wskazywały na domeny atakującego, przechwytując tokeny uprawnień do podejmowania decyzji wykonywanych z poświadczeniami właściciela.
- CVE-2026-101050Średnie
Heym przed wersją 0.0.53 nie weryfikuje nagłówka X-Telegram-Bot-Api-Secret-Token na punktach końcowych webhooków Telegrama, gdy credential_id jest nieobecne lub secret_token jest pusty. Zdalni nieuwierzytelnieni atakujący mogą wysyłać sfałszowane aktualizacje Telegrama, aby wyzwalać przepływy pracy z skonfigurowanymi poświadczeniami właściciela i wykonywać akcje na danych dostarczonych przez atakującego.
- CVE-2026-101049Średnie
Heym przed wersją 0.0.53 nie weryfikuje podpisów żądań Slacka, gdy węzły wyzwalające nie mają identyfikatorów poświadczeń lub mają puste sekrety podpisywania. Zdalni nieuwierzytelnieni atakujący mogą wysyłać sfałszowane zdarzenia Slacka na znane adresy URL webhooków, aby wyzwalać przepływy pracy z poświadczeniami właściciela.
- CVE-2026-100865Wysokie
Podatność w Heym przed wersją 0.0.53, polegająca na ewaluacji wyrażeń warunków przepływu pracy za pomocą eval() w Pythonie z niewystarczającym sandboxingiem w usłudze wykonawczej przepływów pracy.
- CVE-2026-100864Wysokie
heym przed wersją 0.0.91 zawiera podatność ucieczki z sandboxa w silniku wyrażeń (DotList map/filter i fallback resolver), która umożliwia uwierzytelnionym użytkownikom wykonanie dowolnego kodu Python. Atakujący mogą tworzyć wyrażenia workflow z dostępem do atrybutów dunder, aby uzyskać dostęp do os.system i wykonać komendy jako proces backendu.
- CVE-2026-100863Średnie
Heym w wersjach 0.0.90 i wcześniejszych zawiera dwie luki w zabezpieczeniach egress SSRF, obie naprawione w app/services/ssrf_guard.py w wersji 0.0.91. Po pierwsze, loader obrazów LLM (_load_image_bytes) pobierał kontrolowane przez wywołującego adresy URL HTTP/HTTPS za pomocą zwykłego httpx.get, stosując tylko sprawdzenie schematu i omijając klienta HTTP z przypiętym egress. Po drugie, _is_public_address odpakowywał tylko adresy IPv6 mapowane na IPv4, więc formy przejściowe IPv6 — prefiks NAT64 64:ff9b::/96, przestarzałe adresy IPv4-compatible ::x.x.x.x oraz 6to4 (2002::/16) — mogły przenosić adresy loopback, RFC1918, link-local lub cloud-metadata IPv4 poza walidację URL i przypięcie IP przy połączeniu.
- CVE-2026-100862Średnie
Platforma automatyzacji przepływów pracy heym przed wersją 0.0.91 przechowuje i zwraca wiele sekretów w postaci zwykłego tekstu, w tym wartości nagłówków webhook, klucze API MCP, tokeny sesji portalu, tokeny JWT wykonań, tokeny interakcji Discord oraz zmienne globalne. Użytkownik z dostępem do odczytu przepływu pracy, członek zespołu lub osoba mająca dostęp do bazy danych, kopii zapasowej lub logów może odzyskać te sekrety i wykorzystać je do wykonywania przepływów pracy lub podszywania się pod właściciela sekretu.
- CVE-2026-100861Średnie
heym przed wersją 0.0.105 nie stosuje zabezpieczeń egress do usług integracyjnych, które używają adresów bazowych dostarczanych z poświadczeniami, co pozwala uwierzytelnionym użytkownikom na obejście ochrony SSRF. Atakujący mogą skonfigurować poświadczenia wskazujące na adresy loopback, prywatne lub metadane chmury i odczytać odpowiedzi wewnętrznych usług zwracane jako wynik węzła przepływu pracy.
Oryginalny opis (angielski, źródło NVD)
heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node (backend/app/services/node_execution/nodes/redis_node.py). When _get_accessible_credential returns None — because the credential ID does not exist or the caller is not authorized to use it — the node treats the lookup failure as an empty configuration and falls back to defaults, connecting to localhost:6379 with no password and executing the requested operation there. The same fallback occurs when an accessible credential has an empty config or no redis_host value. An authenticated workflow author who supplies a credential ID they do not own, or one that was deleted, therefore obtains a read/write connection to whatever Redis is listening on the backend's loopback interface instead of an error. Impact depends on the deployment: the stock docker-compose.yml ships no Redis, in which case the flaw surfaces as a misleading connection error rather than data exposure.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS