Katalog podatności CVE

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ść typu Code Injection i Expression Language Injection w Apache Camel (wersje 4.4.0–4.18.4, 4.19.0–4.22.0) dotyczy endpointu dynamic-router-control. Producent DynamicRouterControlProducer przyjmował predykat i nazwę języka wyrażeń z przychodzącej wiadomości (pola body lub nagłówki CamelDynamicRouterPredicate i CamelDynamicRouterExpressionLanguage), a następnie kompilował je bez allow-listy i bez opt-in. Umożliwiało to wykonanie dowolnego wyrażenia z uprawnieniami procesu Camel.

Komponent AS2 w Apache Camel (wersje 4.0.0–4.18.4 i 4.19.0–4.22.0) pozwala nadawcy wiadomości wybrać adres asynchronicznego powiadomienia MDN, który Camel następnie odwiedza. Prowadzi to do SSRF z pozycji odbiorcy AS2, w tym do hostów osiągalnych tylko z sieci wewnętrznej, a skonfigurowane dane uwierzytelniające MDN mogą zostać ujawnione atakującemu.

Komponent Netty HTTP w Apache Camel (wersje 4.0.0–4.18.4 i 4.19.0–4.22.0) porównuje ścieżkę żądania z kontekstem bezpieczeństwa z rozróżnianiem wielkości liter, podczas gdy routing tego nie robi. Zmiana wielkości liter w ścieżce pozwala pominąć ograniczenie bezpieczeństwa i dotrzeć do chronionej trasy bez jego spełnienia.

Podatność w komponencie OAuth Apache Camel polega na tym, że procesory camel-oauth chroniące trasę nie zatrzymywały przetwarzania żądania, gdy uwierzytelnienie nie mogło zostać zakończone. W rezultacie nieuwierzytelniony wywołujący mógł dotrzeć do chronionego endpointu, tak jakby uwierzytelnienie się powiodło (model fail-open). Problem dotyczy wersji Apache Camel od 4.11.0 przed 4.18.5 oraz od 4.19.0 przed 4.22.1.

Podatność typu path traversal w komponencie Apache Camel Azure Files pozwala na budowanie ścieżek zdalnych plików poprzez proste sklejenie katalogu z nazwą pliku z listingu serwera, bez normalizacji i sprawdzenia, czy wynik pozostaje w skonfigurowanym katalogu. W efekcie Camel może odczytać, usunąć lub zmienić nazwę plików poza katalogiem pollingowym, używając własnych poświadczeń endpointu. Problem dotyczy wersji Apache Camel od 4.0.0 do 4.18.5 oraz od 4.19.0 do 4.22.1.

Podatność typu path traversal w komponencie SMB Apache Camel pozwala na odczyt, usunięcie lub zmianę nazwy plików poza skonfigurowanym katalogiem zdalnym. Wynika to z braku normalizacji i sprawdzania zawierania się ścieżki podczas łączenia katalogu z nazwą pliku z listingu serwera. Problem dotyczy wersji Apache Camel od 4.2.0 do 4.18.5 oraz od 4.19.0 do 4.22.1.

Podatność typu path traversal w komponencie Apache Camel Mina SFTP pozwala na wyjście poza skonfigurowany katalog zdalny podczas pobierania, usuwania lub zmiany nazwy plików. Nazwa pliku z listingu serwera nie jest normalizowana ani sprawdzana pod kątem zawierania się w katalogu, co umożliwia atakującemu na ścieżce lub złośliwemu serwerowi dostarczenie nazwy z segmentami nadrzędnymi. Problem dotyczy wersji Apache Camel od 4.18.0 do 4.18.5 oraz od 4.19.0 do 4.22.1.

Podatność typu path traversal w komponencie FTP Apache Camel pozwala na odczyt, usunięcie lub zmianę nazwy plików poza skonfigurowanym katalogiem zdalnym. Wynika to z braku normalizacji i sprawdzania zawierania ścieżki podczas łączenia katalogu z nazwą pliku z listingu serwera. Problem dotyczy wersji 4.0.0–4.18.4, 4.19.0–4.22.0 oraz schematów ftp, ftps i sftp.

Podatność deserializacji niezaufanych danych w komponencie Apache Camel Spring Redis. Gdy nie skonfigurowano serializatora, komponent domyślnie używał JdkSerializationRedisSerializer bez filtra ObjectInputFilter, co pozwalało na wykonanie kodu poprzez spreparowane dane w Redis. Problem dotyczy wersji od 2.11.0 do 4.18.5 oraz od 4.19.0 do 4.22.1.

Podatność w komponentach Apache Camel HTTP, Netty HTTP, Undertow i Vert.x HTTP pozwala nadawcy wiadomości nadpisać URI endpointu nagłówkami CamelHttpUri i CamelRestHttpUri, a następnie rozwiązać w tym ciągu placeholdery konfiguracji (zmienne środowiskowe, właściwości systemowe, funkcje sekretów, wywołania beanów). Może to prowadzić do ujawnienia wrażliwych informacji i nieoczekiwanego wywołania metod beanów. 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 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.

Podatność deserializacji niezaufanych danych w Apache Camel dotyczy komponentu camel-hazelcast. Dwie ścieżki konfiguracji (ReplicatedHazelcastAggregationRepository oraz tryb klienta w HazelcastDefaultComponent) nie stosują filtra JavaSerializationFilterConfig, co pozwala atakującemu na zdalne wykonanie kodu poprzez wstrzyknięcie złośliwego obiektu Java do klastra Hazelcast.

W Apache Johnzon występuje podatność Unsafe Reflection — ClassConverter ładuje i statycznie inicjalizuje klasę wskazaną przez atakującego na podstawie niezaufanego JSON. Problem dotyczy wersji od 1.0.0 przed 2.2.0.