Nowo ujawniona podatność w oprogramowaniu do zarządzania planami zajęć otrzymała ocenę 7.3 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) 1. Luka, zidentyfikowana jako CVE-2026-13486, dotyczy systemu SourceCodester Class and Exam Timetabling System w wersji 1.0 2. Publiczne ujawnienie kodu exploita znacząco podnosi ryzyko jego wykorzystania przeciwko niezałatanej infrastrukturze 1.

Problem dotyczy oprogramowania często wykorzystywanego przez mniejsze placówki edukacyjne lub firmy szkoleniowe. Choć sam produkt nie jest szeroko stosowany w Polsce, analiza tej luki stanowi cenną lekcję dla polskich deweloperów i administratorów systemów, zwłaszcza w sektorze edukacji. Wiele polskich uczelni, szkół prywatnych i centrów szkoleniowych korzysta z podobnych, często autorskich lub mało popularnych systemów do zarządzania harmonogramami. Ta podatność pokazuje, jak prosty błąd w walidacji danych wejściowych może prowadzić do pełnej kompromitacji bazy danych.

TL;DR

  • Produkt: SourceCodester Class and Exam Timetabling System 1.0 2.
  • Podatność: CVE-2026-13486, SQL Injection 3.
  • Wektor: Zdalny, poprzez manipulację parametru course_year_section w pliku /preview6.php 4 3 5.
  • Skutek: Zdalne wykonanie dowolnych zapytań SQL, co może prowadzić do kradzieży, modyfikacji lub usunięcia danych (np. dane studentów, oceny, plany zajęć).
  • Ryzyko: Wysokie (CVSS 7.3) 1. Exploit jest publicznie dostępny, co ułatwia przeprowadzenie ataku 1.
  • Kogo dotyczy: Użytkownicy tego konkretnego systemu. Stanowi też ostrzeżenie dla polskich firm i placówek edukacyjnych używających podobnych, niszowych rozwiązań webowych.
  • Pierwszy ruch: Natychmiastowe wyłączenie dostępu do aplikacji z publicznego internetu, jeśli jest używana. Weryfikacja logów serwera WWW pod kątem prób dostępu do pliku /preview6.php.

Wektor ataku

Podatność należy do kategorii CWE-89, czyli klasycznego wstrzyknięcia SQL (SQL Injection). Błąd znajduje się w skrypcie /preview6.php 4. Analiza wskazuje, że dane wejściowe przekazywane przez użytkownika w parametrze course_year_section nie są odpowiednio filtrowane ani escapowane przed użyciem ich w zapytaniu do bazy danych 3.

Atakujący może spreparować specjalny ciąg znaków, który po wstawieniu do zapytania SQL zmienia jego logikę. Na przykład, zamiast oczekiwanej wartości liczbowej lub tekstowej, operator może wysłać fragment kodu SQL, który serwer bazy danych wykona. Atak może być przeprowadzony zdalnie, bez potrzeby uwierzytelnienia 5.

Przykładowy, poglądowy wektor ataku mógłby wyglądać następująco:

http://przykladowa-szkola.pl/preview6.php?course_year_section=1' OR '1'='1

W tym scenariuszu, jeśli aplikacja jest podatna, fragment ' OR '1'='1 spowoduje, że warunek w zapytaniu SQL zawsze będzie prawdziwy. To pozwala ominąć logikę aplikacji i uzyskać dostęp do danych, do których atakujący nie powinien mieć uprawnień. Bardziej zaawansowane payloady mogą wykorzystywać techniki takie jak UNION SELECT do wydobycia zawartości całej bazy danych, w tym nazw tabel, loginów, hashy haseł i danych osobowych studentów czy wykładowców.

Konsekwencje udanego ataku są poważne. Obejmują one:

  • Kradzież danych: Wyciek wrażliwych informacji, takich jak dane osobowe studentów i pracowników, co w polskim kontekście stanowi naruszenie RODO (Rozporządzenie o Ochronie Danych Osobowych).
  • Modyfikację danych: Zmiana ocen, planów zajęć, czy informacji o zapisach.
  • Usunięcie danych: Bezpowrotna utrata kluczowych informacji operacyjnych placówki.
  • Przejęcie serwera: W niektórych konfiguracjach baz danych, udane SQL Injection może prowadzić do zdalnego wykonania kodu na serwerze (RCE), co daje atakującemu pełną kontrolę nad maszyną.

Wskaźniki kompromitacji

Nie dysponujemy klasycznymi wskaźnikami kompromitacji (IoC — Indicators of Compromise), takimi jak hashe plików czy adresy IP serwerów C2 (Command and Control). Jednakże, administratorzy systemów powinni skupić się na monitorowaniu logów serwera WWW w poszukiwaniu prób dostępu do podatnego komponentu. Kluczowe punkty do sprawdzenia to:

  • Ścieżka pliku: Każde żądanie HTTP kierowane do pliku /preview6.php jest podejrzane 4.
  • Parametr: Należy analizować zawartość parametru course_year_section w tych żądaniach pod kątem obecności znaków specjalnych SQL, takich jak apostrofy (’), średniki (;), myślniki (—) lub słów kluczowych (SELECT, UNION, DROP) 3.

Przykładowy wpis w logu serwera Apache mógłby wyglądać tak (przykład poglądowy):

198.51.100.10 - - [10/Oct/2023:13:55:36 +0000] "GET /preview6.php?course_year_section=1'%20UNION%20SELECT%201,2,3-- HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"

Obecność zapytań tego typu jest silnym sygnałem trwającej lub udanej próby eksploitacji.

Co zrobić w 24-48h

Rekomendowane podejście zależy od roli w organizacji. Poniższe kroki nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią podstawę do natychmiastowej reakcji.

Dla administratorów systemu:

  1. Identyfikacja: Sprawdź, czy w Twojej organizacji używany jest SourceCodester Class and Exam Timetabling System 1.0. Jeśli tak, traktuj system jako skompromitowany do czasu pełnej weryfikacji.
  2. Izolacja: Natychmiast wyłącz dostęp do aplikacji z publicznej sieci. Jeśli jest to krytyczny system, ogranicz dostęp tylko do zaufanych adresów IP (np. wewnętrznej sieci placówki lub przez VPN).
  3. Analiza logów: Przeszukaj historyczne logi serwera WWW i bazy danych pod kątem opisanych wyżej wskaźników ataku. Zwróć szczególną uwagę na okres po publicznym ujawnieniu exploita 1.
  4. Aktualizacja: Sprawdź stronę dostawcy oprogramowania w poszukiwaniu łaty bezpieczeństwa. W przypadku braku łaty, system nie powinien być używany.

Dla polskich deweloperów i software house’ów:

  1. Przegląd kodu: Wykorzystaj ten przypadek jako pretekst do przeglądu własnych aplikacji, zwłaszcza tych napisanych w PHP. Zwróć szczególną uwagę na wszystkie miejsca, gdzie dane od użytkownika są wstawiane do zapytań SQL.
  2. Wdrożenie obrony w głąb: Upewnij się, że stosujesz mechanizmy takie jak zapytania parametryzowane (prepared statements) lub solidne biblioteki ORM (Object-Relational Mapping), które domyślnie chronią przed SQL Injection.
  3. Walidacja po stronie serwera: Nigdy nie ufaj danym przychodzącym od klienta. Każdy parametr powinien być walidowany pod kątem typu, długości i dozwolonego formatu.

Dla osób decyzyjnych (dyrekcja, CISO) w polskich placówkach edukacyjnych:

  1. Audyt oprogramowania: Zleć przegląd używanego w organizacji oprogramowania, zwłaszcza niszowych i autorskich rozwiązań. Czy dostawcy prowadzą regularne testy bezpieczeństwa? Jaka jest ich polityka reagowania na incydenty?
  2. Wymagania w przetargach: Wprowadź do procedur zakupowych i przetargowych wymóg dostarczenia przez oferenta raportu z testów bezpieczeństwa lub deklaracji zgodności z dobrymi praktykami tworzenia oprogramowania.
  3. Plan ciągłości działania: Upewnij się, że posiadasz aktualne kopie zapasowe danych z kluczowych systemów, a także procedurę ich odtworzenia w razie awarii lub udanego ataku ransomware, który często jest kolejnym krokiem po kompromitacji serwera.

Źródła

Zobacz też

Przypisy

  1. Exploit został publicznie ujawniony i może być wykorzystany. — nvd.nist.gov › CVE 2026 13486 ↩ ↩2 ↩3 ↩4 ↩5

  2. Wykryto lukę w SourceCodester Class and Exam Timetabling System w wersji 1.0/6.php. — nvd.nist.gov › CVE 2026 13486 ↩ ↩2

  3. Manipulacja argumentu course_year_section może prowadzić do wstrzyknięcia SQL (SQL injection). — nvd.nist.gov › CVE 2026 13486 ↩ ↩2 ↩3 ↩4

  4. Luka dotyczy nieznanej funkcji pliku /preview6.php. — nvd.nist.gov › CVE 2026 13486 ↩ ↩2 ↩3

  5. Atak może zostać przeprowadzony zdalnie. — nvd.nist.gov › CVE 2026 13486 ↩ ↩2