CVE-2026-101049

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.

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.