PTC Windchill: krytyczna deserializacja, SSRF i bypass dostępu

21 sierpnia publiczne bazy opisały trzy nowe problemy w rodzinie PTC. CVE-2026-77645 to krytyczne zdalne wykonanie kodu przez deserializację niezaufanych danych w Windchill i FlexPLM, ocenione na 9,2 w CVSS 4.0. CVE-2026-77646 wykorzystuje deserializację do SSRF w Windchill PDMLink i FlexPLM. CVE-2026-77644 jest krytycznym obejściem kontroli dostępu w Windchill Risk and Reliability Enterprise Edition.

Informacje publiczne są celowo ograniczone, a dokładne pakiety i macierz wydań PTC znajdują się w support articles CS474826 i CS474818. Nie należy dopowiadać endpointu ani gotowego łańcucha na podstawie starszych luk Windchill. Z punktu widzenia obrony wystarcza jednak charakter produktów: system PLM przechowuje projekty, BOM, dokumentację i workflow, integruje się z katalogiem, bazą, CAD, pocztą oraz systemami produkcyjnymi. RCE na tej warstwie ma duży blast radius.

CVE-2026-77645: deserializacja przed uwierzytelnieniem

Rekord CVE mówi o zdalnym wykonaniu kodu w PTC Windchill i PTC FlexPLM przez deserializację niezaufanych danych. Wektor CVSS 4.0 wskazuje sieć, brak wymaganych uprawnień i interakcji użytkownika, ale wysoką attack complexity. Wpływ na podatny system obejmuje pełną poufność, integralność i dostępność, z dodatkowym wpływem na systemy następcze.

Deserializacja jest niebezpieczna, gdy dane z sieci mogą wybrać klasę, graf obiektów lub zachowanie wykonywane podczas odtwarzania. Mitygacja nie polega na filtrowaniu jednego słowa w HTTP. Potrzebna jest poprawka producenta, która ogranicza format, klasy lub osiągalność ścieżki. Reverse proxy i WAF mogą zmniejszyć ekspozycję, lecz bez pełnego wektora nie są równoważne patchowi.

Nie każde wdrożenie ma ten sam kontekst. Windchill bywa publikowany przez SSO, load balancer i WAF albo dostępny tylko przez VPN. Wektor sieciowy nie oznacza koniecznie Internetu; przejęte konto lub host wewnętrzny może osiągnąć aplikację. Dlatego inventory musi obejmować wszystkie nody MethodServer, background MethodServer, klastry DR i środowiska testowe z kopiami danych produkcyjnych.

CVE-2026-77646: SSRF również przez deserializację

Drugi problem dotyczy Windchill PDMLink oraz FlexPLM i może pozwolić serwerowi wykonywać żądania do celu wybranego przez napastnika. Publiczny opis wskazuje deserializację niezaufanych danych, ale nie określa, które schematy, adresy ani odpowiedzi są dostępne. Nie wolno więc twierdzić, że luka na pewno kradnie konkretny cloud credential.

Realny zakres zależy od egressu serwera. MethodServer często widzi bazę, LDAP, repozytoria plików, usługi publikacji, kolejki i wewnętrzne API. W chmurze może mieć także trasę do metadata. Nawet blind SSRF może służyć do skanowania portów i wywoływania endpointów state-changing. Jeśli odpowiedź wraca do atakującego, rośnie wpływ na poufność.

Obrona warstwowa wymaga egress allowlist per rola. Windchill nie powinien dowolnie łączyć się do całego RFC 1918. DNS i proxy wychodzące powinny logować caller, host, resolved IP, port i wynik. Metadata service zabezpiecz przez mechanizmy dostawcy chmury, a identity instancji ogranicz do minimalnych praw.

CVE-2026-77644: osobny produkt WRR

CVE-2026-77644 dotyczy Windchill Risk and Reliability Enterprise Edition, nie należy więc automatycznie przypisywać go każdemu PDMLink. Rekord opisuje critical access control bypass. Źródła klasyfikują problem jako brak uwierzytelnienia dla krytycznej funkcji i nieweryfikowaną zmianę hasła. Potencjalnym skutkiem jest zdalna zmiana poświadczeń konta bez wcześniejszego dostępu.

Właściciel powinien ustalić, czy WRR istnieje jako osobna aplikacja, jaki ma URL, backend identity i kto ją administruje. Systemy niszowe często pozostają poza głównym skanerem i SSO. Aktualizacja Windchill PDMLink nie musi aktualizować WRR; każde ma osobny support article i lifecycle.

Plan reakcji i patchowania

Pobierz CS474826 oraz CS474818 z portalu PTC, sprawdź dokładną wersję, CPS, standalone patch i prerequisites. Nie opieraj się wyłącznie na bannerze HTTP. Zapisz windchill version, listę zainstalowanych CPS, wersje FlexPLM/WRR, customisations oraz nody klastra. PTC może dostarczać poprawki per linia, a własne JAR, JSP i workflow wymagają regresji.

Przed wdrożeniem wykonaj backup bazy, vault/file store, LDAP config, xconf i custom code oraz przetestuj odtworzenie. W klastrze planuj kolejność zgodnie z dokumentacją PTC; mieszanina podatnych i naprawionych nodów za load balancerem nie jest zakończoną mitygacją. Po zmianie potwierdź wersję na każdym MethodServer i obrazie DR.

Test funkcjonalny obejmuje logowanie, wyszukiwanie, checkout/checkin, workflow, publikację CAD, integracje ERP, kolejki, background processing i custom actions. Test bezpieczeństwa ma potwierdzić, że nieautoryzowane żądania są odrzucane, ale nie powinien odtwarzać deserialization RCE na produkcji.

Jeżeli patch czeka, ogranicz aplikację do VPN lub zatwierdzonych źródeł, zamknij niepotrzebne endpointy przez oficjalną mitygację PTC, usuń bezpośredni Internet i zaostrz egress. WAF może blokować anomalie, ale bez podpisu producenta nie daje gwarancji. Nie wyłączaj mechanizmów serializacji na ślepo, bo mogą być wymagane przez workflow.

Hunting po możliwej eksploatacji

Dla RCE przejrzyj procesy potomne JVM, command lines, nowe JSP/JAR/class, pliki w temp i codebase, zadania systemowe, nowe konta, modyfikacje xconf oraz outbound connections. Skoreluj je z access logs, MethodServer logs, load balancerem i EDR. Nietypowy child process Javy jest silnym sygnałem, ale custom publishing może legalnie wywoływać narzędzia, więc potrzebny jest baseline.

Dla SSRF sprawdź połączenia z nodów Windchill do nowych hostów, loopback, link-local, metadata i portów administracyjnych. Analizuj DNS przed połączeniem, bo nazwa może rozwiązać się do adresu prywatnego. Dla WRR szukaj resetów lub zmian haseł bez poprawnej sesji, nagłych logowań po zmianie i nowych kont uprzywilejowanych.

Jeśli są dowody RCE, patching to tylko containment podatności. Izoluj węzeł po uzgodnieniu ciągłości, zabezpiecz pamięć i dyski, rotuj poświadczenia dostępne serwerowi, przejrzyj bazę i file store oraz odbuduj node z zaufanego obrazu. Nie usuwaj webshella przed zabezpieczeniem dowodów. W klastrze napastnik mógł przenieść się między nodami przez wspólny storage lub poświadczenia.

Długoterminowe ograniczenie blast radius

Windchill powinien działać w wydzielonej strefie aplikacyjnej. Load balancer publikuje tylko wymagane ścieżki, administracja idzie osobnym kanałem, database i vault przyjmują ruch wyłącznie z określonych nodów, a egress jest domyślnie zamknięty. Service account nie powinien mieć praw administratora domeny ani szerokiej roli chmurowej.

Customisations muszą przechodzić przegląd deserializacji, uploadu, expression language i command execution. SBOM własnych rozszerzeń oraz rejestr CPS skracają czas oceny. Staging powinien być reprezentatywny, ale nie publiczny i nie używać aktywnych sekretów produkcyjnych.

Fakty producenta i wnioski Breachroad

Produkty, klasy błędów i CVSS pochodzą z rekordów PTC/CVE opublikowanych 20–21 sierpnia oraz support articles. Źródła nie potwierdzają aktywnej eksploatacji i nie udostępniają publicznie pełnego wektora. Dokładne wersje naprawcze trzeba pobrać z portalu PTC dla posiadanej linii.

Segmentacja, egress policy, kolejność huntingu i plan odbudowy są analizą Breachroad. Szkolenia cyberbezpieczeństwa pomagają połączyć PLM, IAM, SOC i produkcję, a audyt bezpieczeństwa IT może zweryfikować wersje, ekspozycję, uprawnienia oraz dowody wdrożenia.

Źródła

• PTC CS474826 — Windchill and FlexPLM security guidance
• PTC CS474818 — Windchill Risk and Reliability guidance
• NVD — CVE-2026-77645
• NVD — CVE-2026-77646
• NVD — CVE-2026-77644