Mastodon
Connect with us

Γλώσσες Προγραμματισμού

Κενό ασφαλείας στο Flowise επιτρέπει απομακρυσμένη εκτέλεση κώδικα

Ένα σοβαρό σφάλμα στο stdio του MCP στο Flowise επιτρέπει RCE με ένα κλικ μέσω εισαγωγής κακόβουλου chatflow, εκθέτοντας API keys, βάσεις δεδομένων και cloud πόρους. Η πλήρης άμβλυνση απαιτεί απενεργοποίηση του stdio ή αυστηρό περιορισμό δικαιωμάτων και έλεγχο εισαγωγών.

Published

on

Κενό ασφαλείας στο Flowise επιτρέπει απομακρυσμένη εκτέλεση κώδικα

Ένα σοβαρό ευάλωτο σημείο στην open-source πλατφόρμα Flowise, που χρησιμοποιείται συχνά για self-hosted εφαρμογές τεχνητής νοημοσύνης, έφερε πάλι στο προσκήνιο τους κινδύνους που προκύπτουν όταν συστήματα AI έχουν δικαίωμα να εκτελούν τοπικές διεργασίες. Ερευνητές της Obsidian Security ανέφεραν ότι μια κακόβουλη εισαγωγή chatflow μπορεί με ένα κλικ να οδηγήσει σε πλήρη απομακρυσμένη εκτέλεση κώδικα (RCE) σε διακομιστές όπου είναι ενεργοποιημένο το MCP stdio.

Η ευπάθεια έχει καταχωρηθεί ως CVE-2026-40933 και της αποδόθηκε βαθμολογία CVSS 9.9, γεγονός που αντικατοπτρίζει το πολύ υψηλό ρίσκο για οργανισμούς που τρέχουν το Flowise εσωτερικά. Στο άρθρο αυτό αναλύουμε τι ακριβώς συμβαίνει, γιατί το πρόβλημα είναι πιο περίπλοκο από αυτό που καλύπτουν οι γρήγορες επιδιορθώσεις και ποιες πρακτικές μπορούν να μειώσουν σημαντικά τον κίνδυνο.

Τι είναι το MCP stdio και γιατί το χρησιμοποιούν εφαρμογές AI

Το MCP (Model Context Protocol) είναι πρωτόκολλο που επιτρέπει σε agents και βοηθούς AI να ξεκινούν και να επικοινωνούν με τοπικές διεργασίες μέσω των ροών εισόδου/εξόδου (stdio). Αυτή η δυνατότητα είναι πολύ χρήσιμη: επιτρέπει σε ένα AI να διαβάζει αρχεία, να τρέχει εντολές για πρόσβαση σε βάσεις δεδομένων ή repositories, να αλληλεπιδρά με browsers για αυτοματοποιημένα tasks ή να χρησιμοποιεί τοπικά credentials για ενσωμάτωση με συστήματα της επιχείρησης.

Για περιπτώσεις όπως RAG (retrieval-augmented generation), αυτοματοποιημένοι assistants ή chatbots που συνδέονται με επιχειρησιακά συστήματα, το stdio MCP προσφέρει τον τρόπο για το μοντέλο να «ενεργεί» στον πραγματικό κόσμο. Όμως ίδιος αυτός δρόμος επικοινωνίας είναι και μια φυσική επιφάνεια επίθεσης όταν οι παραμέτροι που καθορίζουν τις διεργασίες μπορούν να ελεγχθούν από εξωτερικά inputs.

Πώς γίνεται το «ένα κλικ» για RCE

Η βασική αδυναμία που εντόπισαν οι ερευνητές είναι ότι το Flowise επιτρέπει τη δημιουργία ή εισαγωγή MCP stdio ρυθμίσεων οι οποίες περιέχουν αυθαίρετες εντολές προς εκτέλεση από το λειτουργικό σύστημα. Επομένως, όταν ένας χρήστης εισάγει ένα κακόβουλο chatflow —ακόμη και πριν αποθηκευτεί ή εκτελεστεί— το περιεχόμενο μπορεί να ενεργοποιήσει την εκτέλεση εντολών με τα δικαιώματα της διεργασίας του Flowise.

Σε containerized περιβάλλοντα αυτό μπορεί να σημαίνει πρόσβαση επιπέδου root στο container, και ανάλογα με τον τρόπο που είναι ρυθμισμένο το hosting, δυνατότητα κίνησης πλευράς στην υποδομή. Τα αποτελέσματα περιλαμβάνουν υποκλοπή API keys, πρόσβαση σε βάσεις δεδομένων, cloud πόρους και εφαρμογές SaaS που ενδέχεται να έχει δικαιώματα το Flowise.

Γιατί οι αρχικές διορθώσεις δεν αρκούν

Αφού έγινε γνωστό το ζήτημα, η ομάδα του Flowise προχώρησε σε διαδοχικές επιδιορθώσεις που στόχευαν στο να περιορίσουν ή να φιλτράρουν τις εντολές που μπορούν να περάσουν στις stdio διεργασίες. Η πιο σημαντική αλλαγή ήταν η εισαγωγή του CUSTOM_MCP_SECURITY_CHECK, ενός στρώματος ελέγχου για τις ρυθμίσεις Custom MCP. Παρόλα αυτά οι ερευνητές τονίζουν ότι αυτές οι αντιμετρρήσεις βασίζονται σε validation που μπορεί να παρακαμφθεί με διάφορες τεχνικές.

Επιπλέον updates πρόσθεσαν έλεγχο σε flags και επιπλέον φίλτρα, αλλά το θεμελιώδες ζήτημα —η δυνατότητα δηλαδή να εισάγει ένας χρήστης ρυθμίσεις stdio που παράγουν κίνδυνο— παραμένει. Όπως σχολιάζει η Obsidian, το να «περιορίσεις ό,τι γνωρίζεις ότι είναι κακό χωρίς να απενεργοποιήσεις εντελώς λειτουργίες που οι χρήστες χρειάζονται» δεν λύνει το πρόβλημα στο ριζικό του επίπεδο.

Προτεινόμενες πρακτικές και πλήρης άμβλυνση

Οι ερευνητές προτείνουν ως τη μόνη πλήρη άμβλυνση την απενεργοποίηση του stdio MCP με την επιλογή CUSTOM_MCP_PROTOCOL=sse, που αποφεύγει το τοπικό stdio spawn. Όμως για οργανισμούς που δεν μπορούν να απενεργοποιήσουν τη λειτουργία χωρίς να διακόψουν κρίσιμες ροές εργασίας, υπάρχουν μια σειρά από συμπληρωματικά μέτρα:

  • Περιορισμός των δικαιωμάτων του process: τρέξτε το Flowise με τον ελάχιστο απαραίτητο χρήστη και δικαιώματα, όχι ως root ή με υψηλά container privileges.
  • Ενίσχυση containers: εφαρμόστε user namespaces, seccomp, read-only root filesystems και περιορισμό capabilities.
  • Σφιχτό management μυστικών: μην αφήνετε API keys στα περιβάλλοντα, χρησιμοποιήστε secret stores και περιορίστε το scope και το χρόνο ζωής των κλειδιών.
  • Προέλεγχος και validation chatflows: μην αποδέχεστε εισαγωγές από άγνωστες πηγές χωρίς έλεγχο, ψηφιακή υπογραφή ή review από CI/Pipeline.
  • Παρακολούθηση και detection: ρυθμίστε logging για νέα child processes, ασυνήθιστες εντολές, πρόσβαση σε κρίσιμους φακέλους και χρήση εργαλείων runtime detection όπως Falco.
  • Αναβάθμιση και pinning: κλειδώστε εκδόσεις αξιόπιστων πακέτων όπου είναι εφικτό και ενημερώνετε άμεσα μετά από επιδιορθώσεις ασφαλείας.

Τεχνικές λεπτομέρειες του κινδύνου και ο κύκλος ζωής του exploit

Το exploit που περιγράφει η Obsidian περιλαμβάνει την εισαγωγή μιας Custom MCP ρύθμισης που περιέχει μια εντολή ή αλυσίδα εντολών οι οποίες εκτελούνται από το λειτουργικό. Καθώς οι αρχικές επιδιορθώσεις επικεντρώθηκαν σε pattern-based φιλτράρισμα, ένας επιτιθέμενος μπορεί να σπάσει patterns ή να χρησιμοποιήσει έμμεσες τεχνικές (π.χ. script wrappers, encoded payloads, ή αποτελέσματα που ανακαλούν έγκυρες εντολές) για να παρακάμψει τα φίλτρα.

Άλλη επικίνδυνη παράμετρος είναι ότι το σενάριο είναι «post-auth»: σημαίνει πως ο επιτιθέμενος χρειάζεται κάποιο επίπεδο πρόσβασης στον πίνακα του Flowise (π.χ. ως διαχειριστής ή χρήστης που μπορεί να εισάγει chatflows). Όμως πολλοί οργανισμοί δίνουν τέτοια δικαιώματα σε μεγάλο αριθμό ατόμων ή επιτρέπουν την εισαγωγή από συνεργαζόμενα συστήματα, καθιστώντας το attack vector πρακτικά εφικτό σε πολλαπλά σημεία.

Ποιος επηρεάζεται και γιατί έχει μεγάλη σημασία

Οι πιο εκτεθειμένοι είναι οργανισμοί που τρέχουν self-hosted assistants, RAG pipelines ή bots που αλληλεπιδρούν με εσωτερικά συστήματα—ειδικά όταν το Flowise έχει πρόσβαση σε ευαίσθητα αρχεία, αποθετήρια κώδικα, βάσεις δεδομένων ή σύνδεση με third-party APIs. Επιπλέον, περιπτώσεις όπου το Flowise βρίσκεται μέσα σε container clusters με χαλαρές ρυθμίσεις ασφάλειας μπορούν να μεταφράσουν μια αρχική παραβίαση σε πλήρη compromise της υποδομής.

Αντίθετα, Flowise Cloud δεν επηρεάζεται επειδή εκεί το stdio MCP είναι προεπιλεγμένα απενεργοποιημένο. Αυτό δείχνει πως η προεπιλεγμένη ασφάλεια (secure by default) κάνει πραγματική διαφορά: πολλές επιθέσεις εξαλείφονται όταν επικίνδυνες δυνατότητες δεν είναι ενεργές χωρίς ρητή επιλογή του χρήστη.

Τι μπορούν να κάνουν οι ομάδες ανάπτυξης και ασφάλειας τώρα

Ο πρακτικός δρόμος περιλαμβάνει άμεσες και στρατηγικές κινήσεις. Άμεσα, οργανισμοί πρέπει να αξιολογήσουν αν χρησιμοποιούν MCP stdio και να εφαρμόσουν το CUSTOM_MCP_PROTOCOL=sse όπου είναι εφικτό. Για όσους δεν μπορούν, οφείλουν να εφαρμόσουν lockdown σε επίπεδο container, αυστηρό έλεγχο εισαγόμενων chatflows και rotation κλειδιών μετά από κάθε ύποπτο γεγονός.

Σε μεσοπρόθεσμο επίπεδο, είναι σκόπιμο να ενσωματωθούν CI διαδικασίες που σαρώσουν chatflows για επικίνδυνα patterns πριν την εισαγωγή, να χρησιμοποιούν υπογεγραμμένα πακέτα και να προωθούν αλλαγές στο Flowise που καθιστούν τις επικίνδυνες λειτουργίες opt-in με σαφή προειδοποίηση και τεχνικά περιοριστικά μέτρα.

Τι σημαίνει για τους χρήστες και την αγορά

Η περίπτωση του Flowise είναι χαρακτηριστική της ευρύτερης πρόκλησης που αντιμετωπίζει η αγορά των self-hosted AI εργαλείων: η επιδίωξη για λειτουργικότητα και αυτονομή εργαλεια αλληλεπίδρασης με τοπικά συστήματα συγκρούεται συνεχώς με την ανάγκη για ασφαλείς προεπιλογές και κατάλληλο επίβλεψη. Οποιαδήποτε πλατφόρμα δίνει τη δυνατότητα σε μοντέλα να «τρέχουν» εντολές στο λειτουργικό σύστημα πρέπει να σχεδιάζεται με το μοντέλο απώλειας-ελέγχου στο νου, και να θέτει εμπόδια που δεν βασίζονται αποκλειστικά σε pattern blocking.

Για τους τελικούς χρήστες, το μήνυμα είναι σαφές: αν τρέχετε self-hosted AI, δεν αρκεί να εμπιστεύεστε ότι το λογισμικό είναι σωστό· πρέπει να εφαρμόζετε αρχές ελάχιστων προνομίων, να περιορίζετε εισαγωγές από τρίτους και να έχετε ορατότητα για ασυνήθιστες διεργασίες. Η ευθύνη για ασφάλεια είναι κοινή ανάμεσα σε προγραμματιστές της πλατφόρμας και στις ομάδες που τη φέρνουν σε παραγωγή.

Advertisement