Podatności Apache Camel

Apache Camel w wersjach od 2.6.x do 2.14.x, 2.15.x przed 2.15.5 oraz 2.16.x przed 2.16.1, przy użyciu camel-jetty lub camel-servlet jako konsumentów w trasach Camel, umożliwia zdalnym atakującym wykonanie dowolnych poleceń za pomocą spreparowanego zserializowanego obiektu Java w żądaniu HTTP.

Komponent XSLT w Apache Camel przed wersją 2.11.4 oraz 2.12.x przed wersją 2.12.3 umożliwia zdalnym atakującym odczyt dowolnych plików oraz potencjalnie inne nieokreślone skutki poprzez dokument XML zawierający deklarację zewnętrznego bytu w połączeniu z odniesieniem do bytu, co jest związane z problemem XML External Entity (XXE).

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.

Podatność w Apache Camel Atmosphere Websocket component wynika z nieprawidłowej walidacji nagłówków Exchange, które nie należą do przestrzeni nazw Camel (websocket.connectionKey, websocket.connectionKey.list, websocket.sendToAll, websocket.eventType, websocket.errorType). Zewnętrzny atakujący może dostarczyć nagłówek listy przez HTTP i przejąć decyzję o routingu wiadomości do WebSocket, co może prowadzić do pominięcia lub przekierowania powiadomień do innego klienta.

Podatność typu Relative Path Traversal w komponencie Apache Camel Azure Storage Blob umożliwia zapis pliku poza skonfigurowanym katalogiem podczas operacji downloadBlobToFile. Nazwa blobu z segmentami katalogu nadrzędnego nie jest normalizowana, co pozwala na nadpisanie dowolnego pliku w systemie plików z uprawnieniami procesu Camel.

W komponencie Apache Camel AWS SNS wykryto brak filtra dla nagłówków przychodzących w strategii Sns2HeaderFilterStrategy. Podatność nie jest jednak osiągalna, ponieważ komponent jest wyłącznie produkcyjny (nie obsługuje konsumentów), więc atakujący nie może dostarczyć zewnętrznych atrybutów wiadomości do Camel Exchange. Mimo to dodano filtr defensywny dla spójności z innymi strategiami.

W komponencie camel-keycloak Apache Camel wykryto podatność polegającą na pomijaniu weryfikacji tokena dostępu w domyślnej konfiguracji. Gdy wymagane role lub uprawnienia są puste, token nie jest weryfikowany kryptograficznie, co pozwala na dostęp do chronionych tras z dowolnym nagłówkiem Authorization.

Podatność w komponencie DNS Apache Camel umożliwia atak SSRF poprzez nieprawidłową walidację nagłówków wiadomości. Atakujący może ustawić nagłówki dns.server, dns.name i dns.domain w żądaniu HTTP, co prowadzi do przekierowania zapytań DNS na kontrolowany serwer i ujawnienia wewnętrznych nazw hostów.

Podatność w Apache Camel w komponencie mongodb-gridfs pozwala atakującemu na manipulację operacjami GridFS poprzez nagłówki HTTP. Brak walidacji wejścia i kontroli dostępu umożliwia nieautoryzowane usuwanie, odczyt lub wyliczanie plików oraz wstrzykiwanie operatorów NoSQL.

Podatność w komponencie Apache Camel Solr umożliwia ataki typu SSRF oraz wstrzykiwanie parametrów i pól do zapytań Solr. Nagłówki Exchange z prefiksami SolrParam. i SolrField. są przekazywane bez filtrowania z żądań HTTP do producenta Solr, co pozwala atakującemu na manipulację zapytaniami i dokumentami indeksowanymi.

Podatność w komponencie AWS2-SQS Apache Camel pozwala atakującemu na wstrzyknięcie nagłówków kontrolnych Camel (np. CamelHttpUri, CamelFileName) poprzez wiadomości SQS. Brak filtrowania przychodzących nagłówków w Sqs2HeaderFilterStrategy umożliwia modyfikację zachowania producentów w trasie Camel.

W komponencie camel-keycloak Apache Camel brakuje walidacji okresu ważności tokena dostępu. Funkcja pomocnicza nie sprawdza, czy token wygasł lub nie jest jeszcze ważny, przez co akceptuje tokeny poza ich dozwolonym przedziałem czasowym.

Podatność w komponencie Apache Camel Cometd umożliwia atakującemu wstrzyknięcie dowolnych nagłówków sterujących Camel do wymiany komunikatów. Brak filtra nagłówków (HeaderFilterStrategy) powoduje, że nagłówki dostarczone przez klienta CometD, w tym wewnętrzne nagłówki Camel (np. CamelHttpUri, CamelFileName), są kopiowane bez zmian. Domyślnie brak uwierzytelnienia (Bayeux SecurityPolicy) pozwala każdemu klientowi na opublikowanie takiego komunikatu.

Podatność w komponencie camel-pqc Apache Camel umożliwia deserializację niezaufanych danych z AWS Secrets Manager. Luka wynika z braku filtrowania podczas deserializacji obiektów Java, co może prowadzić do zdalnego wykonania kodu.

Podatność w komponencie camel-docling Apache Camel umożliwia wstrzykiwanie argumentów CLI i przechodzenie do katalogów nadrzędnych (directory traversal) poprzez niewystarczającą walidację nagłówków wymiany. Atakujący może dostarczyć nieautoryzowane flagi lub ścieżki wykraczające poza zamierzony katalog, co prowadzi do wykonania nieoczekiwanych operacji przez zewnętrzne narzędzie docling.

Podatność w Apache Camel pozwala na wstrzykiwanie nagłówków wewnętrznych przez niezaufane żądania HTTP do endpointów CXF i Knative. Brak filtrowania przychodzących nagłówków umożliwia atakującemu nadpisanie kluczowych nagłówków Camel, co może prowadzić do zdalnego wykonania kodu lub zapisu dowolnych plików.

Podatność w komponencie Camel-Coap Apache Camel umożliwia nieuwierzytelnionemu atakującemu zdalne wykonanie kodu poprzez wysłanie pojedynczego pakietu UDP CoAP. Brak filtrowania nagłówków powoduje, że parametry zapytania są mapowane bezpośrednio na nagłówki Camel, co pozwala na wstrzyknięcie nagłówków sterujących wykonaniem poleceń systemowych.

Komponent Camel-Mail w Apache Camel nie filtruje nagłówków MIME w kierunku 'in', co pozwala atakującemu na wstrzyknięcie nagłówków Camel poprzez dostarczenie spreparowanej wiadomości e-mail. Podatność dotyczy wersji od 3.0.0 do 4.14.5 oraz od 4.15.0 do 4.18.0.

Podatność w Apache Camel umożliwia zdalne wykonanie kodu poprzez deserializację niezaufanych danych z JMS ObjectMessage. Problem dotyczy komponentów camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq i camel-activemq6.

Poprawka dla CVE-2025-27636 dodała setLowerCase(true) do HttpHeaderFilterStrategy, ale nie została zastosowana do pięciu innych implementacji HeaderFilterStrategy w Apache Camel. Atakujący z dostępem do brokera JMS może wstrzyknąć nagłówki Camel o zmiennej wielkości liter, co prowadzi do zdalnego wykonania kodu i zapisu plików.

Operacje unmarshalling w Apache Camel z użyciem Jackson i JacksonXML są podatne na ataki zdalnego wykonania kodu.

Podatność w komponencie OAuth Apache Camel polega na współdzieleniu statycznego cache tokenów przez wszystkie instancje resolvera w JVM, z kluczem opartym tylko na endpointcie tokena i client ID. Profile różniące się zakresem (scope) lub client secret, ale współdzielące endpoint i client ID, otrzymują nawzajem swoje tokeny, co może prowadzić do użycia tokena o szerszych uprawnieniach lub przeznaczonego dla innej usługi.

FopProducer przetwarza treść XSL-FO, tworząc TransformerFactory przez TransformerFactory.newInstance() i włączając jedynie FEATURE_SECURE_PROCESSING. Gdy w classpath znajduje się zewnętrzna implementacja JAXP, np. Saxon-HE, funkcja ta nie ogranicza dostępu do zasobów zewnętrznych, więc zewnętrzny DTD lub encja w dokumencie XSL-FO są rozwiązywane i rozwijane. Zdalny nadawca może w ten sposób odczytać pliki dostępne dla procesu Camel i wymusić żądania do wskazanych hostów.

Podatność XXE (Improper Restriction of XML External Entity Reference) w komponencie Smooks (camel-smooks) Apache Camel. Domyślny parser Woodstox SAX rozwiązuje zewnętrzne encje i ładuje zewnętrzne DTD, co pozwala atakującemu na odczyt lokalnych plików lub wysyłanie żądań do zasobów sieci wewnętrznej poprzez treść XML. Problem dotyczy wersji od 4.7.0 do 4.18.5 i od 4.19.0 do 4.22.1.

W komponencie Apache Camel HTTP występuje podatność polegająca na użyciu pamięci podręcznej zawierającej wrażliwe informacje. Globalny dla JVM cache tokenów OAuth2 miał klucz pomijający zakres, wskaźnik zasobu i punkt końcowy tokenu, więc dwa różne punkty końcowe mogły współdzielić wpis i otrzymać token o szerszych uprawnieniach niż skonfigurowano.

W komponencie Apache Camel Platform HTTP występuje podatność niewystarczającej granularności kontroli dostępu. Komponent decydował o trybie proxy, sprawdzając czy ścieżka zaczyna się od ciągu "proxy" zamiast dokładnego dopasowania, więc punkty końcowe takie jak proxyStatus czy proxy-config stawały się proxy bez wiedzy autora trasy i przekazywały żądania dalej.

W komponencie Apache Camel gRPC występuje podatność generowania komunikatu błędu zawierającego wrażliwe informacje. Gdy trasa za konsumentem gRPC zawodziła, komunikat wyjątku trafiał do opisu statusu gRPC, który jest przesyłany do klienta, więc zewnętrzny wywołujący mógł odczytać wewnętrzny komunikat błędu zawierający nazwy klas, ścieżki, nazwy hostów i szczegóły połączeń.

W komponencie Apache Camel Mail występuje podatność nieprawidłowej walidacji danych wejściowych. Format danych MimeMultipart przy unmarshalowaniu wiadomości wieloczęściowej mapował nagłówki mail.smtp na Exchange bez filtra, więc zewnętrzny nadawca mógł ustawić te nagłówki i wpłynąć na sposób połączenia i wysyłki przez producenta poczty.

W komponencie Apache Camel Jetty występuje podatność permisywnej polityki cross-domain z niezaufanymi domenami. Ustawienie enableCORS instalowało CrossOriginFilter z domyślnymi wartościami akceptującymi każde pochodzenie i zezwalającymi na poświadczenia, więc strona z dowolnego pochodzenia mogła wykonywać uwierzytelnione żądania cross-origin i czytać odpowiedzi.

W komponencie Apache Camel Core występuje podatność nieprawidłowej walidacji danych wejściowych. Procesor saga odczytywał nagłówek Long-Running-Action bez prefiksu Camel, więc zewnętrzny nadawca mógł go dostarczyć w wiadomości przychodzącej i wskazać sagę, do której dołącza wymiana, przypisując swoje żądanie do akcji rozpoczętej przez kogoś innego.

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.

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.

Podatność w komponencie Apache Camel HTTP polega na ujawnieniu poufnych danych nieautoryzowanemu podmiotowi. Gdy włączono followRedirects=true, poświadczenia (token Bearer OAuth2 oraz dane basic/digest) były ponownie dołączane do żądań kierowanych na host wskazany w nagłówku Location przekierowania, a nie na host skonfigurowany w trasie. Zdalny endpoint mógł więc przechwycić poświadczenia, odpowiadając przekierowaniem na kontrolowany przez siebie host.

Podatność XXE (XML External Entity) w komponencie XPath Apache Camel. Gdy documentType ustawiono na InputSource, XPathBuilder przekazywał dane bezpośrednio do javax.xml.xpath, który tworzył własny DocumentBuilder z domyślnymi ustawieniami JDK, omijając utwardzenia Camel. Zewnętrzny nadawca XML mógł odczytać pliki dostępne dla procesu Camel i wymusić żądania do wskazanych hostów.

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

W Apache Camel Platform HTTP Main wykryto podatność polegającą na nieprawidłowym uwierzytelnianiu JWT. Gdy nie skonfigurowano parametrów jwtIssuer ani jwtAudience, serwer weryfikował tylko podpis i ważność tokena, pomijając całkowicie walidację roszczeń iss i aud. Dotyczy to wersji od 4.8.0 do 4.21.x, a poprawka jest dostępna w wersji 4.22.0.

Podatność typu Relative Path Traversal w komponencie Google Storage Apache Camel umożliwia zapis plików poza skonfigurowanym katalogiem pobierania. Problem dotyczy konsumenta camel-google-storage, który nie normalizuje ścieżek i nie sprawdza, czy cel pozostaje w dozwolonym miejscu, gdy opcja downloadFileName jest ustawiona. Atakujący może wpłynąć na nazwy obiektów w zasobniku, powodując nadpisanie dowolnego pliku z uprawnieniami procesu Camel.