CVE-2026-100864

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.