Luki w Foxit PDF Editor Cloud i Apryse WebViewer: jak „zwykły” PDF może otworzyć drogę do przejęcia konta i eksfiltracji danych - Security Bez Tabu

Luki w Foxit PDF Editor Cloud i Apryse WebViewer: jak „zwykły” PDF może otworzyć drogę do przejęcia konta i eksfiltracji danych

Wprowadzenie do problemu / definicja luki

PDF kojarzy się wielu zespołom z „formatem dokumentu”, a nie z komponentem aplikacyjnym o rozbudowanej logice po stronie klienta i serwera. Tymczasem nowoczesne platformy PDF (webowe edytory, osadzone przeglądarki, SDK do anotacji/konwersji) działają jak pełnoprawne aplikacje: renderują treści, obsługują komunikację międzyramkową, pobierają konfiguracje z URL, wykonują złożone konwersje na backendzie. To wszystko tworzy szeroką powierzchnię ataku.

Badania Novee opisane w lutym 2026 r. pokazały, że podatności w popularnych rozwiązaniach PDF (Foxit PDF cloud services oraz Apryse WebViewer) mogły prowadzić m.in. do account takeover (ATO) i eksfiltracji danych – często przez wektory, które da się „dowieźć” linkiem lub spreparowanym dokumentem.

W skrócie

  • Zidentyfikowano 16 podatności w produktach Foxit i Apryse, z realnymi scenariuszami nadużyć przez złośliwe dokumenty, URL-e lub wiadomości.
  • Kluczowe klasy błędów obejmowały m.in. DOM XSS, stored/reflected XSS, SSRF, path traversal oraz OS command injection.
  • Novee szczegółowo opisało m.in. przypadek DOM XSS w Apryse WebViewer przez parametr konfiguracji UI (uiConfig), który może prowadzić do jednoklikowego ATO w aplikacjach, gdzie viewer jest osadzony w kontekście zalogowanego użytkownika.
  • Foxit opublikował aktualizacje w swoim Trust Center / biuletynach bezpieczeństwa dla komponentów chmurowych (np. PDF Editor Cloud).

Kontekst / historia / powiązania

W praktyce enterprise Apryse WebViewer bywa osadzany w aplikacjach intranetowych i systemach obiegu dokumentów jako iframe/webcomponent, a Foxit PDF Editor Cloud działa jako przeglądarkowa platforma do edycji i podpisu. To powoduje, że „błąd w viewerze” nie jest tylko błędem w narzędziu – bywa błędem w zaufanym komponencie aplikacji, często działającym na domenie organizacji lub na domenach whitelistingowanych w politykach bezpieczeństwa (CSP, proxy, SSO).

Co istotne, Novee akcentuje typowy problem architektoniczny: przekraczanie granic zaufania (trust boundaries). W WebViewer wejściem bywa nie tylko sam PDF, ale też parametry URL, postMessage, zdalne pliki konfiguracyjne, localStorage — czyli kanały, które w wielu wdrożeniach nie są traktowane jak dane nieufne.

Analiza techniczna / szczegóły luki

1) Apryse WebViewer: DOM XSS przez zdalną konfigurację UI (uiConfig)

W opisywanym scenariuszu WebViewer UI pobiera z parametru uiConfig adres URL do pliku JSON z konfiguracją, a następnie używa wybranych pól tej konfiguracji w sposób prowadzący do niebezpiecznego sinka w DOM (XSS). Novee pokazało łańcuch: link → pobranie zdalnego JSON → wstrzyknięcie do UI → wykonanie JS w ramce viewera.

Warto zwrócić uwagę na „detail, który boli”: nawet jeśli część klasycznych payloadów SVG/JS jest neutralizowana przez parser, Novee opisuje obejście przez foreignObject, gdzie przeglądarka przełącza się w kontekst HTML i zdarzenia (np. onerror) mogą się wykonać.

Dlaczego to eskaluje do ATO?
Jeśli viewer działa w aplikacji wymagającej logowania, XSS w jego kontekście może umożliwić przejęcie sesji (tokenów), wykonywanie akcji jako użytkownik, a w niektórych integracjach – dostęp do API przez istniejące uprawnienia frontendu. Novee deklaruje, że w realnym środowisku osiągnęło „one-click account takeover” dla klienta.

2) Apryse WebViewer: stored DOM XSS w metadanych anotacji

Drugim przykładem jest stored XSS, gdzie payload trafia do dokumentu/obiektu anotacji (np. pole autora), a następnie jest renderowany w panelu komentarzy/notes w sposób prowadzący do innerHTML. Taki ładunek może przetrwać odświeżenia i wykonywać się przy re-renderze UI (np. po interakcji użytkownika).

3) Foxit PDF Editor Cloud: luki w komponentach webowych i obsłudze komunikatów

W biuletynach Foxit pojawia się m.in. opis problemu, w którym usługa pluginów (używana przez PDF Editor Cloud) mogła być podatna na XSS przy obsłudze spreparowanego postMessage, gdy handler nie weryfikował origin i podstawiał zewnętrzną ścieżkę jako źródło skryptu. To klasyczny przykład: błąd walidacji pochodzenia + dynamiczne ładowanie skryptu = zdalne wykonanie JS.

4) Inne klasy błędów: SSRF, path traversal, OS command injection

SecurityWeek podsumował, że w zestawie 16 podatności znalazły się także SSRF, path traversal i OS command injection. W ekosystemie PDF to szczególnie groźne, bo serwerowe komponenty (konwersje HTML→PDF, generowanie miniaturek, import zasobów) często pobierają URL-e i przetwarzają pliki, co może otwierać drogę do dostępu do zasobów wewnętrznych lub wykonania poleceń przy słabych kontrolach.

Praktyczne konsekwencje / ryzyko

Najbardziej niebezpieczny wzorzec to sytuacja, w której PDF viewer jest:

  1. osadzony w aplikacji dostępnej po zalogowaniu,
  2. działa na zaufanej domenie (lub w kontekście SSO),
  3. akceptuje dane wejściowe z URL/wiadomości/dokumentu bez twardych ograniczeń.

Wtedy XSS potrafi przeskoczyć z „ot, pop-up alert” do:

  • przejęcia sesji i ATO,
  • eksfiltracji dokumentów (np. z viewerów, paneli komentarzy, integracji storage),
  • manipulacji treścią (zmiana adnotacji, redakcji, pól formularza),
  • utrwalonej kompromitacji (payload, który wraca przy kolejnych renderach/odświeżeniach).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów utrzymujących Apryse WebViewer / Foxit Cloud

  1. Natychmiastowe aktualizacje komponentów (SDK/WebViewer, usługi chmurowe, pluginy) oraz weryfikacja, czy wdrożono wydania zawierające poprawki. Obaj dostawcy zadeklarowali, że luki zostały załatane po odpowiedzialnym zgłoszeniu.
  2. Zablokowanie/ograniczenie zdalnych konfiguracji:
    • jeśli używacie mechanizmów typu uiConfig/remote config, ograniczcie je do listy dozwolonych hostów (allowlist) i wymuście HTTPS + podpisy/hashe,
    • rozważcie całkowite wyłączenie ładowania konfiguracji z parametru URL, jeśli nie jest konieczne.
  3. CSP z sensem:
    • ogranicz script-src (bez unsafe-inline), włącz nonces/hashes tam, gdzie to możliwe,
    • rozważ frame-ancestors i konsekwentne polityki dla subdomen viewera.
  4. Sandbox dla iframes (jeśli architektura pozwala): minimalny zestaw uprawnień, bez zbędnych allow-same-origin / allow-scripts (w praktyce to trudne, ale warto przynajmniej ocenić).
  5. Twarda walidacja postMessage:
    • weryfikacja origin,
    • walidacja schematu wiadomości,
    • zakaz dynamicznego ładowania skryptów/zasobów na podstawie danych z wiadomości.
  6. Monitoring i detekcja nadużyć:
    • anomalia w linkach otwierających viewer (nietypowe parametry, zewnętrzne uiConfig, zewnętrzne dokumenty),
    • alerty na żądania do nietypowych domen z kontekstu viewera,
    • telemetry na błędy i wyjątki JS (często poprzedzają skuteczne payloady).

Dla SOC/Blue Team

  • Traktujcie PDF/viewery jako high-risk web component, a nie „czytnik dokumentów”.
  • Przeglądnijcie miejsca osadzenia (gdzie viewer siedzi w kontekście SSO, gdzie ma dostęp do API, gdzie jest na tej samej domenie co app).
  • Dodajcie przypadki testowe do DAST: parametry URL, remote config, postMessage, notatki/komentarze/anotacje.

Różnice / porównania z innymi przypadkami

  • Apryse WebViewer: ryzyko często wynika z elastyczności integracji (konfiguracje, osadzanie w iframe, bogaty UI i re-rendering), co zwiększa szansę na DOM XSS i podatności „na styku” danych zaufanych i niezaufanych.
  • Foxit PDF Editor Cloud: nacisk na usługi webowe i komponenty chmurowe (w tym komunikacja między komponentami, pluginy, message passing), gdzie częste są błędy walidacji origin/źródeł danych.
  • Wspólny mianownik: PDF to nie tylko parser pliku — to platforma (frontend + backend), a podatności webowe (XSS/SSRF) potrafią być równie groźne jak klasyczne błędy pamięci w silnikach renderujących.

Podsumowanie / kluczowe wnioski

  1. Nie ufajcie viewerom PDF „z definicji” — w nowoczesnych wdrożeniach to komponent aplikacyjny o dużym wpływie na bezpieczeństwo.
  2. XSS w osadzonym viewerze może realistycznie prowadzić do account takeover i eksfiltracji danych, zwłaszcza gdy viewer działa w kontekście zalogowanej aplikacji.
  3. Największe ryzyko ogranicza kombinacja: aktualizacje + ograniczenie wejść (URL/config/postMessage) + CSP + izolacja (iframe/sandbox) + monitoring.

Źródła / bibliografia

  • SecurityWeek: „Vulnerabilities in Popular PDF Platforms Allowed Account Takeover, Data Exfiltration” (18 lutego 2026) (SecurityWeek)
  • Novee Labs: „From PDF to Pwn: Scalable 0day Discovery in PDF Engines and Services Using Multi-Agent LLMs” (18 lutego 2026) (Novee)
  • Foxit: Security Bulletins / aktualizacje dla Foxit PDF Editor Cloud (m.in. release 3 lutego 2026) (Foxit)
  • Apryse: dokumentacja dot. hardeningu WebViewer Server (kontekst dobrych praktyk) (docs.apryse.com)