Katalog podatności CVE

Wtyczka EmbedPress przed wersją 4.6.7 nie escapuje jednego ze swoich atrybutów bloku przed wyświetleniem go wewnątrz atrybutu HTML. Może to umożliwić użytkownikom z rolą Contributor i wyższą przeprowadzanie ataków Stored Cross-Site Scripting przeciwko użytkownikom o wyższych uprawnieniach przeglądającym wpis.

Wtyczka WebFacing™ przed wersją 5.4 nie ogranicza dostępu do jednego ze swoich dołączonych skryptów oraz nie waliduje ścieżki podanej przez użytkownika przed użyciem jej do dołączenia lokalnego pliku. Umożliwia to nieuwierzytelnionym użytkownikom przeprowadzenie ataku Local File Inclusion.

Wtyczka WordPress UpdraftPlus: WP Backup & Migration Plugin w wersjach przed 1.26.8 oraz przed 2.26.8.26 nie sprawdza uprawnień w procedurze, która wyświetla zapisane ustawienia zdalnej pamięci masowej na stronach administracyjnych, gdy witryna znajduje się w określonym stanie po migracji. W efekcie każdy zalogowany użytkownik, nawet o roli subskrybenta, może odczytać dane uwierzytelniające skonfigurowanych miejsc docelowych kopii zapasowych, takie jak hasła i klucze tajne.

Wtyczka WordPress Ad Inserter w wersjach przed 2.8.19 nie ogranicza prawidłowo dostępu do jednej ze swoich stron ustawień, przez co jest ona osiągalna dla każdego zalogowanego użytkownika w konfiguracji dozwolonej przez jej własne ustawienia, oraz nie filtruje zapisywanej tam treści. Umożliwia to użytkownikom o roli tak niskiej jak subskrybent zapisanie kodu, który jest następnie wykonywany jako PHP lub wyświetlany odwiedzającym witrynę bez escapowania.

Podatność w coollabsio Coolify do wersji 4.1.0 dotyczy funkcji Github::redirect w pliku /webhooks/source/github/redirect komponentu GitHub App Setup Handler. Manipulacja argumentem state prowadzi do braku uwierzytelnienia. Atak może być wykonany zdalnie, a exploit jest publiczny. Wersja 4.1.1 zawiera poprawkę.

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.

Heym przed wersją 0.0.106 zawiera podatność na eksfiltrację poświadczeń w punkcie końcowym POST /api/credentials/test, która pozwala współpracownikom z dostępem do współdzielonych poświadczeń na wyeksfiltrowanie sekretu właściciela poświadczeń. Atakujący mogą nadpisać docelowy URL w parametrze config, aby serwer wysyłał odszyfrowane sekrety uwierzytelniające do kontrolowanych przez atakującego punktów końcowych.

heym przed wersją 0.0.109 zawiera podatność na SSRF w węzłach Slack, Discord i Crawler. Węzły te wysyłają żądania HTTP do adresów URL pochodzących z poświadczeń użytkownika (webhook_url / flaresolverr_url) za pomocą niechronionego klienta HTTP, omijając zabezpieczenia egress. Każdy zarejestrowany użytkownik może utworzyć poświadczenie wskazujące na wewnętrzny adres i wykonać przepływ pracy, powodując dostęp do punktów końcowych loopback, prywatnych, link-local lub metadanych chmury i zwrócenie pełnej treści odpowiedzi w wyniku węzła.

AzuraCast przed wersją 0.23.4 zawiera podatność wstrzykiwania kodu w metodzie ConfigWriter::cleanUpString(), która nie sanitizuje sekwencji interpolacji Liquidsoap. Uwierzytelnieni użytkownicy z uprawnieniami Media lub Profile mogą wstrzyknąć dowolny kod Liquidsoap do konfiguracji stacji, co prowadzi do wykonania poleceń powłoki jako użytkownik azuracast przy restarcie stacji.

AzuraCast przed wersją 0.23.6 zawiera podatność wstrzykiwania kodu w polu hasła zdalnego przekaźnika z powodu niepełnej migracji z podatnej metody cleanUpString do toRawString. Atakujący z uprawnieniami RemoteRelays mogą wstrzyknąć zagnieżdżoną składnię interpolacji Liquidsoap, aby wykonać dowolny kod w procesie Liquidsoap, ujawnić wewnętrzne klucze API lub zakłócić działanie stacji.

AzuraCast przed wersją 0.23.6 zawiera brak sprawdzenia uprawnień w punkcie końcowym GET /api/station/{station_id}/file/{id}/play, co pozwala uwierzytelnionym użytkownikom na pobieranie plików multimedialnych z dowolnej stacji. Atakujący mogą enumerować pliki za pomocą sekwencyjnych identyfikatorów i eksfiltrować całą bibliotekę multimediów stacji, do których nie mają uprawnień.

AzuraCast przed wersją 0.23.6 nie stosuje middleware RequireInternalConnection na punkcie końcowym API Liquidsoap i błędnie wyprowadza flagę AutoDJ z obecności nagłówka, a nie z jego zweryfikowanej wartości. Użytkownicy z uprawnieniem View station mogą wstrzykiwać dowolne metadane now-playing, zakłócać transmisje na żywo i ujawniać ścieżki systemu plików.

W AzuraCast przed wersją 0.23.8 publiczny punkt końcowy pobierania On-Demand nie weryfikuje kontroli dostępu na poziomie playlisty, co pozwala nieuwierzytelnionym użytkownikom na pobieranie plików multimedialnych wykluczonych z playlist z włączonym On-Demand. Atakujący mogą ominąć zamierzone ograniczenia dostępu, bezpośrednio żądając mediów za pomocą prawidłowych identyfikatorów, ujawniając prywatne lub zastrzeżone treści audio.

Podatność na wstrzykiwanie poleceń w AzuraCast przed wersją 0.23.8, występująca w generowaniu konfiguracji Liquidsoap dla nagrań na żywo. Brak odpowiedniego cytowania nazwy użytkownika streamera w wywołaniach process.run.

AzuraCast przed wersją 0.23.8 zawiera podatność uszkodzonej kontroli dostępu w endpointcie GET /api/station/{id}/vue/profile, która umożliwia uwierzytelnionym użytkownikom z uprawnieniem View Station Page odczytanie haseł administratora, źródła i przekaźnika Icecast/Shoutcast. Atakujący z dostępem tylko do podglądu może wywołać ten endpoint i otrzymać jawne poświadczenia frontendu w odpowiedzi JSON, a następnie użyć hasła administratora do uwierzytelnienia w interfejsie administracyjnym Icecast bez uprawnień Broadcasting.