CVE-2026-55376

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 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.

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.