ujawnienie informacji

Ujawnienie informacji to podatność, przez którą aplikacja udostępnia informacje wrażliwe podmiotowi, który nie ma wyraźnego upoważnienia do dostępu do nich ^[1]. W katalogu CWE odpowiada jej słabość CWE-200 ^[1]. Nazwa opisuje błąd w oprogramowaniu, a nie zdarzenie. Samo zdarzenie, w którym dane faktycznie wypłynęły, to wyciek danych, a przy danych osobowych naruszenie ochrony danych osobowych w rozumieniu RODO.

Jak działa

MITRE opisuje trzy drogi, którymi informacja wydostaje się z aplikacji ^[1]:

• wstawienie jawne — kod celowo umieszcza dane w odpowiedzi, choć powinien je usunąć;
• wstawienie pośrednie — inny błąd ubocznie ujawnia dane, na przykład pełną ścieżkę systemową w komunikacie błędu;
• niezamierzony dostęp — zasoby z danymi stają się dostępne z powodu osobnej podatności.

Informacja nie musi być tajna sama w sobie, by była groźna. Ścieżka do katalogu, wersja bazy danych albo nazwa użytkownika skracają atakującemu rozpoznanie i pozwalają dobrać kolejny krok. Schemat poniżej pokazuje, jak drobne ujawnienie staje się częścią łańcucha ataku.

RYS. 1Ujawnienie informacji w łańcuchu ataku

Odmiany

MITRE wymienia rodzaje informacji, które mogą zostać ujawnione: dane prywatne, takie jak wiadomości, dane finansowe, zdrowotne i lokalizacyjne; szczegóły systemu, w tym system operacyjny i zainstalowane pakiety; tajemnice przedsiębiorstwa; konfigurację sieci; kod lub stan aplikacji; metadane, na przykład logi połączeń i nagłówki wiadomości ^[1]. Słabości potomne CWE-200 opisują najczęstsze kanały.

Do tej grupy należą też zjawiska opisane w osobnych hasłach: ujawnianie wersji, enumeracja użytkowników, listowanie katalogów (directory listing) i publicznie dostępne pliki wrażliwe, czyli zapomniane kopie, eksporty bazy i pliki konfiguracyjne. W zestawieniach ogólnych spotyka się też szersze pojęcie ujawnienia informacji wrażliwych (sensitive data exposure).

W WordPressie

Najczęstszym źródłem ujawnienia w WordPressie jest tryb debugowania na produkcji. Dokumentacja wyjaśnia, że stała WP_DEBUG włącza tryb debugowania w całym WordPressie, i odradza używanie jej oraz innych narzędzi debugowania na działających witrynach, bo są przeznaczone do testów lokalnych i instalacji testowych ^[3]. Przy włączonym WP_DEBUG_DISPLAY komunikaty są domyślnie wypisywane w HTML stron ^[3], więc każdy odwiedzający widzi ścieżki plików i nazwy funkcji.

Drugim źródłem jest log. WP_DEBUG_LOG zapisuje błędy domyślnie do pliku wp-content/debug.log ^[3]. Dokumentacja pliku wp-config.php stwierdza, że umieszczanie logów błędów w miejscach publicznie dostępnych jest zagrożeniem bezpieczeństwa, i zaleca trzymanie ich powyżej katalogu publicznego witryny ^[4]. Gdy to niemożliwe, proponuje ochronę pliku regułami w .htaccess ^[4], co opisuje hasło zabezpieczenia w .htaccess.

// wp-config.php na produkcji
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

W kodzie wtyczek i motywów ujawnienie przybiera zwykle prostsze formy. Przykłady to punkty końcowe REST API zwracające więcej pól, niż potrzeba, pliki eksportu zapisywane w katalogu uploads bez ochrony i komunikaty, które różnią się w zależności od tego, czy konto istnieje.

Zagrożenia i skutki

MITRE klasyfikuje skutek jako odczyt danych aplikacji, czyli naruszenie poufności ^[1]. Dla CWE-209 opisuje, jak komunikat błędu pomaga w dalszym ataku: błąd SQL ujawnia strukturę bazy, próba path traversal ujawnia ścieżki plików, a szczegóły zapytania ułatwiają kolejne kroki ^[2]. Ujawnienie bywa więc przygotowaniem do SQL injection albo do przejęcia konta.

Najpoważniejsze skutki ma ujawnienie danych uwierzytelniających, kluczy API i haseł do usług zewnętrznych. Atakujący nie musi wtedy łamać zabezpieczeń, bo dostaje gotowy klucz. Ocena wagi zależy więc od tego, co wypływa, a nie od samego mechanizmu. Ta sama funkcja wypisująca szczegóły błędu jest drobnym problemem, gdy pokazuje numer wiersza w pliku, i poważnym, gdy pokazuje treść zapytania z hasłem do bazy. Dlatego przy przeglądzie podatności tej klasy trzeba ustalić, jakie dane są dostępne, dla kogo i bez jakiego uwierzytelnienia. Ujawnienie danych osobowych może dodatkowo rodzić obowiązki administratora wobec organu nadzorczego i osób, których dane dotyczą.

Jak się bronić

MITRE zaleca podział systemu na strefy, w których granice zaufania da się jednoznacznie wyznaczyć, z rozdziałem uprawnień ^[1], zgodnie z zasadą najmniejszych uprawnień. Dla komunikatów błędów zalecenia są konkretne ^[2]:

• komunikat zawiera tylko minimum szczegółów przydatnych dla adresata;
• szczegóły błędu trafiają do logu, a nie na ekran, przy czym log nie może zawierać haseł;
• komunikaty nie powinny zdradzać, czy dane konto istnieje;
• informacje debugowania nie trafiają do wersji produkcyjnej, a w PHP należy wyłączyć display_errors;
• domyślne strony błędów są ogólne i nic nie ujawniają.

W WordPressie oznacza to wyłączony tryb debugowania na produkcji, log poza katalogiem publicznym, przegląd katalogów wp-content i uploads pod kątem zapomnianych plików oraz przegląd tego, co zwracają punkty końcowe REST API dla niezalogowanych.

Historia i przykłady

CERT Polska 3 września 2026 roku opisał podatność CVE-2026-15933 w OptimiDoc Server: oprogramowanie przechowywało poświadczenia do usług zewnętrznych jawnym tekstem, a administrator widział skonfigurowane hasła do SMTP, FTP, Active Directory i SharePoint w źródle strony panelu ^[5]. Problem usunięto w wersji 26.08 ^[5].

Ujawnienie informacji bywa też skutkiem błędu pamięci. CERT Polska 14 maja 2026 roku opisał CVE-2026-8295 w bibliotece simdjson: przepełnienie liczby całkowitej prowadziło do przydzielania zbyt małych buforów i odczytów poza nimi, co mogło powodować ujawnienie informacji lub uszkodzenie pamięci ^[6]. Podatne były wersje poniżej 4.6.4 ^[6].