Katalog podatności CVE

W komponencie Keycloak Apache Camel występuje błąd nieprawidłowego uwierzytelniania. Procesor bezpieczeństwa sprawdzał wystawcę tokenu tylko wtedy, gdy odpowiedź introspekcji zawierała roszczenie iss; jego brak powodował pominięcie weryfikacji zamiast błędu, co mogło pozwolić na akceptację tokenu od niewłaściwego wystawcy.

W komponencie PQC Apache Camel występuje błąd nieprawidłowych domyślnych uprawnień. Podczas zapisu wygenerowanego materiału klucza na dysk stosowano uprawnienia wynikające z domyślnej maski umask procesu, zamiast ograniczyć plik tylko do właściciela, co mogło umożliwić odczyt klucza prywatnego innym lokalnym kontom.

W komponencie AS2 Apache Camel występuje błąd ujawnienia elementu danych niewłaściwej sesji. Materiał podpisujący należący do pojedynczego żądania był przechowywany w stanie współdzielonym między żądaniami, co przy wielu partnerach handlowych mogło prowadzić do podpisania powiadomienia MDN kluczem innego partnera.

Podatność w komponencie Apache Camel MLLP polega na zapisywaniu wrażliwych danych (treści komunikatów HL7, w tym danych pacjentów) do zwykłych logów aplikacji. Opcja logPhi domyślnie miała wartość true, a dodatkowo dwie ścieżki kodu logowały payload niezależnie od jej ustawienia. Problem dotyczy wersji Apache Camel od 4.0.0 do 4.18.5 oraz od 4.19.0 do 4.22.1.

Podatność w komponencie Apache Camel CXF polega na ujawnianiu informacji wrażliwych w komunikatach błędów SOAP. Gdy trasa za konsumentem SOAP CXF kończy się wyjątkiem, którego kontrakt usługi nie deklaruje, szczegóły wyjątku (nazwy klas, pakietów, treść komunikatu, a opcjonalnie stos wywołań) są zwracane klientowi w faultstring lub fault detail. Problem dotyczy Apache Camel w wersjach od 4.0.0 do 4.18.5 oraz od 4.19.0 do 4.22.1.

W komponencie Platform HTTP Apache Camel występuje błąd nieprawidłowej obsługi wielkości liter. Zabezpieczenie zapobiegające odbiciu nagłówka żądania w odpowiedzi porównywało nazwy nagłówków z rozróżnianiem wielkości liter, podczas gdy nazwy nagłówków HTTP są niewrażliwe na wielkość liter, co pozwalało obejść ochronę poprzez zmianę wielkości liter, a w HTTP/2 ochrona była nieskuteczna dla każdego żądania.

W komponencie Tika Apache Camel występuje błąd nieprawidłowej walidacji danych wejściowych. Producent Tika mapował każdy klucz metadanych sparsowany z dokumentu na nagłówek Exchange bez filtrowania, co pozwalało na ustawienie nagłówków przestrzeni nazw Camel, takich jak CamelFileName, przez treść dokumentu kontrolowaną przez atakującego.

W komponencie PQC Apache Camel występuje błąd warunku wyścigu polegający na współbieżnym wykonaniu ze współdzielonym zasobem i nieprawidłową synchronizacją. Producent używał jednej instancji java.security.Signature dla wszystkich wymian bez synchronizacji, co przy współbieżnym ruchu powodowało przeplatanie wywołań update i verify.

Podatność w komponencie Apache Camel Knative polega na nieprawidłowej walidacji certyfikatów. Gdy SSL był włączony w kliencie HTTP Knative, ale nie skonfigurowano truststore, klient ufał każdemu przedstawionemu certyfikatowi zamiast domyślnym zaufanym certyfikatom JVM. Atakujący znajdujący się na ścieżce sieciowej może przechwycić i odczytać zaszyfrowane połączenie.

Podatność w komponencie Apache Camel Mina polega na ujawnianiu szczegółów wyjątków zdalnemu peerowi w przypadku niepowodzenia przetwarzania wymiany. W zależności od użytego kodeka (textline lub object) atakujący może odczytać nazwy klas, komunikaty, a nawet serializowany wyjątek z łańcuchem przyczyn, co może ujawnić ścieżki, nazwy hostów i szczegóły połączeń. Problem dotyczy wersji Apache Camel od 4.0.0 do 4.18.5 oraz od 4.19.0 do 4.22.1.

Podatność w komponencie Apache Camel Thrift polega na tym, że dane wejściowe są deserializowane do współdzielonego obiektu defaultInstance zamiast do nowej kopii. Powoduje to, że stan jednej wiadomości pozostaje widoczny dla kolejnych wiadomości tego samego typu, co może prowadzić do ujawnienia danych między różnymi nadawcami.

Podatność w komponencie Apache Camel Crypto PGP polega na nieprawidłowej walidacji kodu wykrywania modyfikacji. Funkcja unmarshal() weryfikowała integralność tylko dla wiadomości w formacie OpenPGP symmetrically encrypted integrity protected data packet, pomijając starszy packet bez kodu integralności, co pozwalało nadawcy lub osobie modyfikującej wiadomość w tranzycie decydować o zastosowaniu sprawdzenia integralności.

Podatność w komponencie Apache Camel Shiro polega na pominięciu weryfikacji poświadczeń, gdy podmiot już powiązany z bieżącym wątkiem ma ten sam principal co przychodząca wymiana. Ponieważ wątki są pobierane z puli i współdzielone, podmiot pozostawiony przez wcześniejszą uwierzytelnioną wymianę może spełnić warunek dla późniejszej wymiany bez ważnych poświadczeń.

Podatność w komponencie Apache Camel Knative polega na ujawnianiu szczegółów wyjątku w odpowiedzi HTTP zwracanej do zdalnego wywołującego. Gdy przetwarzanie wymiany nie powiodło się po stronie konsumenta, w treści odpowiedzi zwracano nazwę klasy, komunikat i stos wywołań wyjątku. Zewnętrzny nadawca mógł wywołać błąd i odczytać wewnętrzne informacje o wdrożeniu, takie jak nazwy klas i pakietów, nazwy plików lub hostów oraz strukturę trasy.

Podatność Cross-Site Request Forgery (CSRF) w komponencie OAuth Apache Camel wynika z braku powiązania parametru state z sesją podczas przepływu kodu autoryzacji. Callback nie weryfikował parametru state, co umożliwiało atakującemu podstawienie własnego kodu autoryzacji i zalogowanie ofiary na konto atakującego. Dodatkowo niezwalidowany callback pozwalał na otwarte przekierowanie z zaufanego źródła.

Podatność w komponencie Apache Camel Platform HTTP Vertx polega na nieprawidłowej konfiguracji CORS: nagłówek Access-Control-Allow-Credentials: true jest wysyłany niezależnie od wyniku weryfikacji originu, a przy braku ustawienia camel.server.cors.origins handler odbija dowolny origin w Access-Control-Allow-Origin. W efekcie dowolna strona może wykonywać uwierzytelnione żądania cross-origin do endpointu Camel i odczytywać odpowiedzi.

Podatność w komponencie Apache Camel Docling polega na niejawnym wyborze trybu przetwarzania treści wiadomości na podstawie jej prefiksu (http://, https://, / lub \), co umożliwia atakującemu wywołanie SSRF, path traversal oraz ujawnienie wrażliwych informacji. Brak opcji przypięcia trybu oraz niewystarczająca walidacja ścieżek pozwalają na dostęp do zdalnych zasobów lub lokalnych plików bez zgody wdrożenia.

W Apache Answer do wersji 2.0.2 występuje nieprawidłowa implementacja algorytmu uwierzytelniania. Błąd w integracji logowania User Center może powodować, że nowo utworzona sesja użytkownika zewnętrznego pomija swoją tożsamość zewnętrzną, pozwalając kolejnym żądaniom ominąć kontrole zawieszenia lub usunięcia konta do czasu wygaśnięcia lub unieważnienia sesji.

W Apache Answer do wersji 2.0.2 występuje ujawnienie poufnych informacji przez zapytania do danych. Nieprawidłowa kontrola autoryzacji w wyszukiwaniu podobnych pytań pozwalała uwierzytelnionym użytkownikom przeglądać metadane niepublicznych pytań.

W Apache Answer do wersji 2.0.2 nieuwierzytelnieni atakujący mogą uzyskać dostęp do komentarzy powiązanych z treściami niepublicznymi poprzez publiczne profile użytkowników. Luka wynika z niewystarczającej kontroli widoczności komentarzy.