Μια σοβαρή ευπάθεια στο επίσημο Python SDK του Model Context Protocol (MCP) εκθέτει εταιρικούς λογαριασμούς και αυτόνομους AI agents σε πλήρη υποκλοπή διαπιστευτηρίων OAuth. Το κενό ασφαλείας επιτρέπει σε κακόβουλους MCP servers να παγιδεύσουν τη διαδικασία ταυτοποίησης σε πλατφόρμες όπως η Google, η Okta και το Microsoft Entra ID. Εάν αναπτύσσεις εφαρμογές τεχνητής νοημοσύνης που συνδέονται με εξωτερικά APIs, τα συστήματά σου κινδυνεύουν άμεσα με παραβίαση.
- Τι συνέβη: Εντοπίστηκε κενό ασφαλείας στο MCP Python SDK που παρακάμπτει το πρωτόκολλο PKCE και διαρρέει ευαίσθητα OAuth tokens σε κακόβουλους servers.
- Ποιοι επηρεάζονται: Όλες οι υλοποιήσεις με εκδόσεις 1.9.1–1.29.1 και 2.0.0–2.1.1 που επικοινωνούν με μη αξιόπιστους HTTP servers.
- Η άμεση λύση: Άμεση αναβάθμιση στις εκδόσεις 1.30.0 ή 2.2.0, ρητός ορισμός του παραμέτρου
issuerκαι ανάκληση ενεργών διαπιστευτηρίων.
Πώς λειτουργεί το OAuth exploit στο MCP SDK
Το Model Context Protocol αποτελεί το ανοιχτό πρότυπο της Anthropic που επιτρέπει σε γλωσσικά μοντέλα (LLMs) να αλληλεπιδρούν με εξωτερικές βάσεις δεδομένων και υπηρεσίες cloud. Όταν ένας client ζητά πρόσβαση σε προστατευμένους πόρους, εκτελεί διαδικασία ανακάλυψης (OAuth discovery) για να εντοπίσει τον authorization server. Εκεί ακριβώς ξεκινά η παραβίαση.
Όπως αποκάλυψε η ομάδα της Cycode, ένας κακόβουλος MCP server επιστρέφει σκόπιμα σφάλμα 404 στο σύγχρονο discovery request. Αυτή η ενέργεια αναγκάζει το SDK να καταφύγει σε έναν παρωχημένο μηχανισμό fallback, αποδεχόμενο ρυθμίσεις OAuth κατευθείαν από τον μη αξιόπιστο server χωρίς επικύρωση του πραγματικού εκδότη (issuer).
Ο επιτιθέμενος σερβίρει τη νόμιμη σελίδα εισόδου της Google ή της Microsoft, διατηρώντας την εμπιστοσύνη του χρήστη. Ωστόσο, ανακατευθύνει το OAuth token endpoint σε δική του υποδομή. Μόλις ολοκληρωθεί η σύνδεση, το SDK παραδίδει στον επιτιθέμενο όχι μόνο τον κωδικό εξουσιοδότησης (authorization code) αλλά και το μυστικό PKCE verifier, αχρηστεύοντας κάθε προστασία έναντι υποκλοπής διαπιστευτηρίων.
Interactive logins έναντι Machine-to-Machine αυτοματισμών
Η επικινδυνότητα της ευπάθειας διαφέρει ανάλογα με το σενάριο υλοποίησης. Στις διαδραστικές συνεδρίες (Interactive OAuth), ο επιτιθέμενος χρειάζεται τη συμμετοχή του χρήστη για να πατήσει είσοδο, βαθμολογώντας την απειλή με CVSS 6.5. Παρόλα αυτά, το θύμα βλέπει το γνήσιο domain ταυτοποίησης στο browser, γεγονός που καθιστά την επίθεση σχεδόν αόρατη σε έλεγχο ρουτίνας.
Στα περιβάλλοντα μηχανής-προς-μηχανή (M2M) μέσω ClientCredentialsOAuthProvider ή PrivateKeyJWTOAuthProvider, η κατάσταση γίνεται δραματική. Εκεί δεν απαιτείται καμία ανθρώπινη παρέμβαση, με το σκορ επικινδυνότητας να εκτοξεύεται στο CVSS 7.5. Τα scripts αντλούν δεδομένα στο παρασκήνιο και αποστέλλουν τα tokens απευθείας στις κακόβουλες διευθύνσεις.
Η κακή διαχείριση διαπιστευτηρίων σε backend υποδομές μπορεί να εκθέσει ευαίσθητα εταιρικά API tokens χωρίς καμία προειδοποίηση στα συστήματα SIEM. Η εμπειρία μας σε enterprise ελέγχους δείχνει ότι οι αυτοματοποιημένες M2M συνδέσεις σπάνια ελέγχονται για αλλαγές στο endpoint routing.
| Τύπος Provider | CVSS Score | Απαιτείται Χρήστης; | Ευάλωτες Εκδόσεις |
|---|---|---|---|
| OAuthClientProvider | 6.5 (Medium) | Ναι (Phishing landing) | 1.9.1–1.29.1 / 2.0.0–2.1.1 |
| ClientCredentials / PrivateKeyJWT | 7.5 (High) | Όχι (Πλήρως Αυτόνομο) | 1.9.1–1.29.1 / 2.0.0–2.1.1 |
| Local stdio clients | Ασφαλές (N/A) | Όχι | Δεν επηρεάζεται |
Το μεγάλο κενό στην ασφάλεια των αυτόνομων AI Agents
Η πλειονότητα των αναλύσεων περιορίζεται στην περιγραφή του τεχνικού bug, παραβλέποντας τον κρίσιμο ρόλο της εφοδιαστικής αλυσίδας των AI agents. Σήμερα, τα σύγχρονα αυτόνομα συστήματα αναζητούν και επιλέγουν MCP servers δυναμικά από δημόσια registries χωρίς να μεσολαβεί ανθρώπινος έλεγχος διαμόρφωσης.
Αυτό σημαίνει ότι τεχνικές όπως το typosquatting σε ονόματα servers, το DNS poisoning ή επιθέσεις prompt injection μπορούν να εξαναγκάσουν έναν agent να συνδεθεί σε rogue endpoints. Εάν ο agent εμπιστευτεί τον εν λόγω server, παραδίδει τα κλειδιά της υποδομής σου στο πιάτο.
Το ρίσκο δεν αφορά μόνο servers που φιλοξενούνται σε απομακρυσμένα clouds. Ακόμη και εσωτερικά δίκτυα που χρησιμοποιούν HTTP MCP endpoints εκτίθενται αν κάποιος τοπικός server παραβιαστεί, μετατρέποντας το MCP client σε όχημα πλευρικής μετακίνησης (lateral movement) για τους εισβολείς.
Βήματα άμεσης αποκατάστασης και ρυθμίσεις ασφαλείας
Η επίλυση του ζητήματος απαιτεί άμεση αναβάθμιση του πακέτου mcp στο περιβάλλον Python σου. Η ομάδα ανάπτυξης διόρθωσε το πρόβλημα στις εκδόσεις 1.30.0 (για τον κλάδο 1.x) και 2.2.0 (για τον κλάδο 2.x), επιβάλλοντας αυστηρό έλεγχο ταυτότητας του issuer σε κάθε discovery μονοπάτι.
Εάν στον κώδικά σου χρησιμοποιείς ClientCredentialsOAuthProvider ή PrivateKeyJWTOAuthProvider, η αναβάθμιση των βιβλιοθηκών από μόνη της δεν αρκεί. Οφείλεις να προσθέσεις ρητά την παράμετρο issuer= κατά την αρχικοποίηση του provider, ώστε να απορρίπτονται οποιαδήποτε metadata προέρχονται από μη εξουσιοδοτημένους servers.
Παράλληλα, εάν η υποδομή σου συνδέθηκε έστω και μία φορά σε άγνωστο ή τρίτο HTTP server, θεώρησε τα διαπιστευτήρια παραβιασμένα. Προχώρησε άμεσα σε ανάκληση όλων των ενεργών tokens, ανακύκλωσε τα client secrets στους παρόχους ταυτότητας (Okta, Azure AD κ.λπ.) και διάγραψε τις παλιές αποθηκευμένες εγγραφές OAuth στο σύστημά σου.
Η άποψή μας στο TechNoid
Η συγκεκριμένη ευπάθεια αποδεικνύει την επικίνδυνη βιασύνη με την οποία υιοθετούνται τα frameworks τεχνητής νοημοσύνης. Οι προγραμματιστές συχνά αντιμετωπίζουν τα εργαλεία των LLMs ως έμπιστους εσωτερικούς συνομιλητές, αγνοώντας βασικές αρχές Zero Trust δικτύωσης.
Το να επιτρέπεις σε έναν απομακρυσμένο server να καθορίζει πού θα αποσταλεί το PKCE code verifier αποτελεί θεμελιώδες αρχιτεκτονικό σφάλμα. Το MCP είναι ένα εξαιρετικό πρωτόκολλο διασύνδεσης, όμως αν το χρησιμοποιείς σε παραγωγικό περιβάλλον χωρίς τοπικό έλεγχο ταυτότητας και απομόνωση δικτύου, αφήνεις την κερκόπορτα της επιχείρησής σου ορθάνοιχτη.
Συχνές Ερωτήσεις για την ευπάθεια του MCP SDK
Επηρεάζονται οι τοπικές υλοποιήσεις MCP μέσω stdio;
Όχι, οι clients που επικοινωνούν τοπικά μέσω standard input/output (stdio) δεν επηρεάζονται, καθώς το πρόβλημα αφορά αποκλειστικά HTTP-based MCP συνδέσεις.
Ποιες εκδόσεις του MCP Python SDK είναι ευάλωτες;
Ευάλωτες είναι όλες οι εκδόσεις από 1.9.1 έως 1.29.1 στον κλάδο 1.x, καθώς και από 2.0.0 έως 2.1.1 στον κλάδο 2.x.
Αρκεί μόνο η αναβάθμιση του πακέτου με pip install;
Όχι πλήρως. Αν χρησιμοποιείς M2M providers, πρέπει επιπλέον να ορίσεις ρητά την παράμετρο issuer= και να ανακαλέσεις παλιά client secrets.
Πώς καταλαβαίνω αν ο AI agent μου έχει πέσει θύμα της επίθεσης;
Έλεγξε τα logs για απαντήσεις 404 κατά το OAuth discovery ή για εξερχόμενες συνδέσεις σε μη εγκεκριμένα OAuth token endpoints.
Προστατεύει το πρωτόκολλο PKCE από αυτή την ευπάθεια;
Όχι, διότι το SDK έστελνε το PKCE verifier απευθείας στον κακόβουλο server, επιτρέποντάς του να ολοκληρώσει νόμιμα την ανταλλαγή με τον identity provider.
Επηρεάζονται SDKs γραμμένα σε άλλες γλώσσες όπως TypeScript;
Η συγκεκριμένη αναφορά εστιάζει αποκλειστικά στην υλοποίηση του επίσημου Python SDK, αλλά συνιστάται έλεγχος σε κάθε HTTP client υλοποίηση.
