pavanchow/cve-2026-33234SSRF via smtplib raw TCP sockets bypassing HTTP blocklist in AutoGPT SendEmailBlock
CVE-2026-33234 | Modéré 5.0 | GHSA-4jwj-6mg5-wrwf Auteur : Pavan Nallamothu
Je cartographiais chaque entrée contrôlée par l'utilisateur qui touchait au réseau dans la plateforme AutoGPT. La couche HTTP était verrouillée de manière stricte. Les plages d'adresses IP privées (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), le loopback, les endpoints de métadonnées cloud — tout était sur liste noire. J'ai confirmé la passerelle HTTP sous plusieurs angles. Rien ne passait.
Puis j'ai ouvert le schéma de configuration du SendEmailBlock.
Le champ serveur SMTP était une entrée en texte libre. Pas une information d'identification d'administrateur. Pas une configuration verrouillée définie une fois au déploiement. Un champ que n'importe quel utilisateur authentifié pouvait remplir avec ce qu'il voulait. J'ai tracé le chemin du code et découvert que ouvre un socket TCP brut. Cette connexion ne passe jamais par le chemin HTTP où se trouve la liste noire d'adresses IP. Deux chemins sortants existaient dans la plateforme. Un seul était protégé.
smtplib.SMTP()J'ai pointé le serveur SMTP vers localhost:22.
La bannière SSH est revenue dans le message d'erreur. smtplib se connecte à ce que vous lui donnez, tente de lire un message d'accueil SMTP 220, et lorsqu'il reçoit autre chose, enveloppe les octets bruts dans une SMTPConnectError. Cette exception se propage à travers le framework d'exécution d'AutoGPT et apparaît proprement dans la sortie du bloc. Je regardais la chaîne de version SSH de la cible sans jamais toucher à la couche HTTP.
C'est ce qui rendait la chose intéressante. smtplib n'est pas seulement un client e-mail. C'est un récupérateur de bannières TCP avec un rapport d'erreurs structuré. Pointez-le vers le port 6379 et vous obtenez la signature de protocole de Redis. Pointez-le vers un port fermé et ConnectionRefusedError vous indique que l'hôte est vivant mais que le port est down. Pointez-le vers 169.254.169.254:80 et vous confirmez que l'endpoint de métadonnées cloud est accessible. Chaque tentative de connexion renvoie une erreur différente et informative. SSRF non aveugle via une fonctionnalité censée envoyer des e-mails.
La conception de SMTPConfig aggrave le problème. Dans une architecture sécurisée, l'adresse du serveur SMTP serait une information d'identification contrôlée par l'administrateur — définie une fois, verrouillée, jamais exposée aux utilisateurs. Au lieu de cela, c'est une entrée par exécution. Chaque utilisateur authentifié contrôle où la plateforme ouvre des connexions TCP.
# Configuration de SendEmailBlock - définir le serveur SMTP sur des cibles internes
# Scanner SSH
smtp_server = "10.0.0.5"
smtp_port = 22
# L'erreur révèle : "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6"
# Scanner Redis
smtp_server = "10.0.0.5"
smtp_port = 6379
# L'erreur révèle : "-ERR unknown command ..."
# Scanner un port fermé
smtp_server = "10.0.0.5"
smtp_port = 9999
# L'erreur révèle : "ConnectionRefusedError" (port fermé, hôte vivant)
# Toucher les métadonnées cloud
smtp_server = "169.254.169.254"
smtp_port = 80
# Confirme l'accessibilité de l'endpoint de métadonnées
J'ai vérifié toute la chaîne via l'API d'exécution des blocs :
# Test direct équivalent contre l'API d'exécution des blocs
curl -X POST https://autogpt-platform/api/blocks/execute \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{
"block_id": "send_email_block",
"inputs": {
"smtp_server": "10.0.0.5",
"smtp_port": 22,
"to": "[email protected]",
"subject": "test",
"body": "test"
}
}'
# La réponse contient SMTPConnectError avec la bannière SSH
graph LR
A[L'attaquant définit le serveur SMTP sur une IP interne] --> B[SendEmailBlock appelle smtplib.SMTP]
B --> C[Connexion TCP brute vers cible:port]
C --> D{Le service répond-il ?}
D -->|Oui| E[La bannière est lue comme message d'accueil SMTP]
E --> F[SMTPConnectError avec données de bannière]
F --> G[L'erreur se propage à la sortie du bloc]
D -->|Non| H[ConnectionRefused = port fermé]
G --> I[L'attaquant lit la version du service]La surface d'attaque que cela ouvre est significative. Les bannières SSH révèlent des versions exactes (OpenSSH_8.9p1 Ubuntu-3ubuntu0.6). Redis fuit sa signature de protocole. MySQL envoie sa chaîne de version. Chaque bannière est une recherche de CVE en attente. Un attaquant cartographie le réseau interne, identifie chaque service en cours d'exécution et sa version exacte, puis cible le plus faible. Tout cela à partir d'un champ texte intitulé « Serveur SMTP ».
Trois contrôles manquants ont créé cela : aucune validation d'adresse IP sur le chemin SMTP, aucune restriction de port, aucune assainissement des exceptions. La plateforme protégeait chaque porte sortante sauf celle intitulée « courrier sortant ».
J'ai signalé le problème à Significant Gravitas. Ils ont immédiatement compris la lacune architecturale.
Corrigé dans : autogpt-platform-backend 0.6.52 (validation du serveur SMTP ajoutée à l'application de la liste noire, restrictions de port appliquées)