Ruflo to platforma open source dostępna na GitHub do zarządzania agentami AI. Zdobyła ponad 67 tysięcy gwiazdek i zajęła drugie miejsce na MCPMarket.

Jak poważna była luka w Ruflo?

Otrzymała ocenę CVSS 10, czyli najwyższą możliwą, co oznacza krytyczną podatność umożliwiającą pełne przejęcie systemu.

Czy luka została naprawiona?

Tak, zespół wydał poprawkę w ciągu kilku godzin od zgłoszenia przez badaczy z Noma Labs.

Jakie dane były zagrożone?

Atakujący mogli uzyskać dostęp do kluczy API dostawców usług LLM, historii rozmów w bazie MongoDB oraz ustanowić trwały dostęp do systemu.

Czy jeszcze mogę używać Ruflo?

Tak, ale wymagana jest aktualizacja do wersji zawierającej poprawkę bezpieczeństwa, która wymusza uwierzytelnianie i wyłącza potencjalnie niebezpieczne narzędzia.

Ruflo: krytyczna luka w platformie agentów AI zagrażała bezpieczeństwu

Platforma Ruflo miała podatność CVSS 10, która umożliwiała przejęcie całego środowiska agentów AI jednym żądaniem HTTP.

Platforma Ruflo, popularna aplikacja do zarządzania agentami sztucznej inteligencji, miała krytyczną lukę bezpieczeństwa, którą odkryli badacze z Noma Labs. Podatność otrzymała ocenę CVSS 10 — maksymalną możliwą — co oznacza, że zagrażała całkowitemu przejęciu systemu przez każdego, kto znalazłby sposób jej wykorzystania.

Jak wyglądała luka w Ruflo?

Ruflo to narzędzie open source rozpowszechniane za pośrednictwem GitHub, gdzie zyskało zaufanie społeczności — licznik pokazuje ponad 67 tysięcy gwiazdek. Platforma zajęła również drugie miejsce na MCPMarket, co świadczy o jej popularności wśród użytkowników zainteresowanych automatyzacją opartą na agentach AI.

Serce problemu znajdowało się w komponencie zwanym MCP Bridge — serwerze Express.js, który stanowił interfejs do interakcji z narzędziami dostępnymi w systemie. Ten most komunikacyjny udostępniał aż 233 narzędzia, ale bez żadnego mechanizmu uwierzytelniania. Oznaczało to, że każdy, kto miał dostęp do portu 3001 (na którym nasłuchiwał serwer), mógł wysłać zwykłe żądanie HTTP POST i uzyskać pełny dostęp do funkcjonalności systemu.

Jakie były praktyczne skutki tej podatności?

Atakujący nie musiał posiadać żadnego tokenu, klucza API ani innego poświadczenia. Wystarczył jeden, prosty request HTTP skierowany na odpowiedni endpoint, aby uzyskać możliwość:

Wykonywania dowolnych poleceń powłoki systemu operacyjnego
Przeglądania i modyfikowania baz danych
Zarządzania agentami AI działającymi w środowisku
Kradzieży kluczy API powiązanych z dostawcami usług LLM (takimi jak OpenAI czy Anthropic)
Dostępu do pełnej historii rozmów zapisanej w bazie MongoDB
Ustanowienia trwałego backdoora, czyli ukrytego dostępu do systemu

Szczególnie niebezpieczne było narzędzie o nazwie ruflo__terminal_execute, które wykonywało polecenia powłoki z uprawnieniami UID 1000 kontenera Docker. Atakujący działałby zatem w kontekście użytkownika aplikacji, co dało by mu dostęp do wszystkich zasobów, do których ma dostęp ten użytkownik.

Dlaczego port 3001 był dostępny dla każdego?

Domyślna konfiguracja w pliku docker-compose.yml mapowała port 3001 na adres 0.0.0.0, co oznacza, że serwer nasłuchiwał na wszystkich interfejsach sieciowych. W praktyce oznaczało to, że jeśli kontener Ruflo był dostępny w sieci (nawet tylko lokalnie), każdy w tej sieci mógł się z nim połączyć.

Dodatkowo, endpoint /mcp omijał listę zablokowanych poleceń (konfigurację AUTOPILOT_BLOCKED_PATTERNS), co oznacza, że nawet jeśli administratorzy próbowali ograniczyć dostęp do niebezpiecznych operacji, ten konkretny endpoint ignorował te ograniczenia.

Co to oznacza dla użytkowników Ruflo?

Jeśli ktoś uruchamiał Ruflo w produkcji bez dodatkowych warstw zabezpieczeń (takich jak firewall czy reverse proxy z uwierzytelnianiem), jego system był w pełni narażony na przejęcie. Zagrożenie dotyczyło szczególnie organizacji, które:

Korzystały z Ruflo do zarządzania agentami AI obsługującymi ważne procesy biznesowe
Przechowywały w systemie klucze API do płatnych usług LLM
Miały zapisaną historię rozmów zawierającą wrażliwe dane
Nie miały dodatkowych warstw bezpieczeństwa sieci

Jak szybko została naprawiona luka?

Zespół Ruflo wykazał się szybkością — poprawka trafiła do repozytorium w ciągu kilku godzin od zgłoszenia podatności. Aktualizacja wprowadza kilka istotnych zmian:

Element	Przed poprawką	Po poprawce
Uwierzytelnianie MCP Bridge	Brak	Wymóg tokenu MCP_AUTH_TOKEN
Narzędzie terminal_execute	Domyślnie włączone	Domyślnie wyłączone
Konfiguracja CORS	Brak	Dodana
Dostęp do portu 3001	Otwarty (0.0.0.0)	Wymaga ponownej konfiguracji

Najważniejsza zmiana to wprowadzenie wymagania tokenu uwierzytelniającego dla każdego żądania do MCP Bridge. Bez poprawnego tokenu żaden request nie zostanie przetworzony, niezależnie od tego, skąd pochodzi.

Co powinni zrobić użytkownicy Ruflo?

Każdy, kto ma wdrożoną platformę Ruflo, powinien niezwłocznie:

Sprawdzić, czy korzysta z wersji zawierającej poprawkę bezpieczeństwa
Upewnić się, że port 3001 nie jest dostępny z publicznego internetu
Jeśli jeszcze nie zaktualizował, wykonać update i ponownie uruchomić kontenery
Zmienić wszystkie klucze API, które mogły być przechowywane w systemie (na wypadek, gdyby luka była wcześniej wykorzystana)
Przejrzeć logi dostępu do systemu, aby sprawdzić, czy nie było nieautoryzowanych prób dostępu

Szerszy kontekst: bezpieczeństwo platform AI

Incydent z Ruflo ilustruje ważny problem w ekosystemie narzędzi AI — narzędzom do automatyzacji i zarządzania agentami czasem brakuje domyślnych mechanizmów bezpieczeństwa. Deweloperzy skupiają się na funkcjonalności, a bezpieczeństwo trafia na drugi plan. Jednak gdy platforma zarządza agentami AI, które mają dostęp do kluczy API i danych biznesowych, brak uwierzytelniania staje się krytycznym zagrożeniem.

Pozytywnym aspektem jest to, że badacze z Noma Labs odpowiedzialnie zgłosili podatność, a zespół Ruflo szybko ją naprawił. To pokazuje, że nawet w szybko rozwijającym się obszarze AI możliwa jest efektywna współpraca między badaczami bezpieczeństwa a twórcami oprogramowania.