CVE-2026-45806

La fonction d'importation d'images distantes de Penpot permettait à un éditeur de fichier authentifié de transformer une fonctionnalité multimédia normale en SSRF d'origine serveur, car des URL contrôlées par l'attaquant tombaient dans un chemin de récupération serveur suivant les redirections, sans filtrage de destination.

Introduction

J'ai découvert ce problème en examinant Penpot, la plateforme open-source de conception et de collaboration sur le code, avec une question très spécifique en tête :

Que se passe-t-il lorsqu'un outil de conception collaborative permet à un utilisateur de fournir au backend une URL d'image distante à récupérer ?

Dans ce cas, cette question a conduit à un véritable bug.

Le flux d'importation d'images distantes de Penpot acceptait une URL contrôlée par l'utilisateur et faisait récupérer cette URL par le backend depuis le contexte réseau du serveur, sans imposer de restrictions de destination pour les cibles loopback ou réseau privé. Le client HTTP partagé suivait également automatiquement les redirections.

Cela a transformé une fonctionnalité multimédia normale en une primitive SSRF d'origine serveur authentifiée, et est finalement devenu CVE-2026-45806.

Penpot : Penpot sur GitHub
CVE : CVE-2026-45806
CVSS : CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Cela affectait Penpot. Sur son site officiel et son kit média, Penpot se présente comme ayant une base d'utilisateurs en croissance de plus d'un million et indique que des dizaines de milliers d'organisations l'utilisent, notamment Blender, Mozilla, Fedora, NTT Data, MIT, Société Générale, Cisco, Fujitsu, Indra et ByteDance.

Chaîne d'attaque

éditeur de fichier authentifié -> URL d'image distante contrôlée par l'attaquant -> create-file-media-object-from-url -> récupération d'image backend download-image avec redirections activées -> requête finale atterrit sur un point de terminaison d'image interne uniquement -> SSRF d'origine serveur / atteignabilité interne

Ce que fait Penpot

Penpot est une plateforme open-source de conception et de collaboration sur le code.

Elle gère des choses comme :

• l'édition collaborative de fichiers
• les workflows d'équipe et de projet
• les médias et ressources téléchargées
• les chemins de rendu et d'aperçu
• les opérations de conception basées sur le navigateur, soutenues par le traitement côté serveur

Cela signifie que son chemin d'importation multimédia se situe sur une véritable frontière de confiance.

La question importante n'était pas de savoir si Penpot prend en charge l'importation d'images distantes.

La vraie question était :

Penpot restreint-il l'endroit où le backend est autorisé à se connecter lorsqu'un utilisateur importe une image distante ?

Dans ce cas, ce n'était pas le cas.

Pourquoi ce bug méritait d'être examiné

Beaucoup de gens sous-estiment les fonctionnalités d'importation distante.

C'est une erreur.

Dès qu'une application :

• accepte une URL contrôlée par l'attaquant,
• effectue la requête depuis le backend,
• et transforme cette requête en un workflow produit normal,

elle crée une véritable frontière de confiance sortante.

C'était le problème ici.

Ce bug ne se situait pas dans le rendu d'image. Il ne se situait pas dans le stockage de fichiers. Il ne se situait pas dans les vérifications d'autorisations ordinaires pour l'édition d'un fichier.

C'était un classique échec de confiance côté serveur :

• une URL contrôlée par l'attaquant entrait dans le système,
• le backend la récupérait directement,
• les redirections étaient autorisées,
• et aucun contrôle de destination n'était visible dans le chemin examiné.

C'est suffisant pour créer une véritable vulnérabilité.

La frontière sur laquelle je me suis concentré

Je n'ai pas abordé Penpot en fuzzeant aveuglément des méthodes RPC aléatoires ou en recherchant d'abord des crashs.

L'approche plus solide consistait à identifier la frontière de sécurité la plus prometteuse.

Pour Penpot, c'était l'importation de médias distants.

Pourquoi ?

Parce que cette fonctionnalité combine :

• une entrée d'URL contrôlée par l'attaquant
• des requêtes sortantes d'origine serveur
• une validation de contenu qui n'a lieu qu'après que la requête est faite
• un workflow de conception où les récupérations réussies sont traitées comme des opérations médiatiques normales

C'était la bonne frontière à inspecter.

Et c'était exactement là où se trouvait le bug.

Cause racine

Le bug se réduit à une petite chaîne de confiance.

Dans le frontend :

(defn upload-media-url
  [name file-id url]
  (rp/cmd!
   :create-file-media-object-from-url
   {:name name
    :file-id file-id
    :url url
    :is-local true}))

L'url contrôlée par l'utilisateur est envoyée directement dans l'appel RPC.

Ensuite, dans le backend :

(sv/defmethod ::create-file-media-object-from-url
  ...
  [{:keys [::db/pool] :as cfg} {:keys [::rpc/profile-id file-id] :as params}]
  (files/check-edition-permissions! pool profile-id file-id)
  ...
  (let [_    (files/get-minimal-file cfg file-id)
        mobj (create-file-media-object-from-url cfg (assoc params :profile-id profile-id))])

et :

(defn- create-file-media-object-from-url
  [cfg {:keys [url name] :as params}]
  (let [content (media/download-image cfg url)

le backend vérifie que l'appelant peut éditer le fichier cible, puis passe l'URL contrôlée par l'attaquant dans media/download-image.

L'implémentation de la récupération est ici :

(defn download-image
  "Download an image from the provided URI and return the media input object"
  [{:keys [::http/client]} uri]
  ...
  (http/req! client
             {:method :get :uri uri}
             {:response-type :input-stream})

Et le client HTTP partagé est configuré comme suit :

(http/build-client {:connect-timeout 30000
                    :follow-redirects :always}))

C'est toute la vulnérabilité :

• l'attaquant contrôle l'URL
• le backend effectue la requête
• les redirections sont suivies automatiquement
• aucun filtrage de destination n'est appliqué avant l'exécution de la requête

Pourquoi c'est exploitable

Parce que l'attaquant a seulement besoin :

• d'un compte Penpot valide
• d'une permission d'édition sur un fichier
• d'une cible qui renvoie un contenu d'image accepté

La chaîne d'attaque est simple :

• l'attaquant fournit une URL
• Penpot la récupère depuis le backend
• le premier saut peut être public ou apparemment inoffensif
• la cible de redirection peut être interne
• si la réponse finale ressemble à une image autorisée, l'importation se termine

C'est tout le bug.

Ce qui fait de cela un problème de sécurité, pas seulement un comportement d'importation distant normal

La distinction importante est où la requête se produit.

La question n'est pas :

"Penpot peut-il importer des images à partir d'URL ?"

La vraie question est :

"Un utilisateur authentifié peut-il faire en sorte que le backend de Penpot se connecte à des destinations internes que l'utilisateur ne devrait pas pouvoir atteindre via l'application ?"

Dans ce cas, la réponse était oui.

Cela compte car il y a une réelle différence entre :

• un navigateur qui récupère une URL fournie par l'utilisateur, et
• le backend qui récupère cette URL depuis la position réseau du serveur

La validation d'image ne supprime pas cette différence.

Elle réduit certains cas d'exfiltration directe, mais elle ne supprime pas la condition SSRF ni la rupture de frontière réseau.

Preuve de concept (PoC)

J'ai validé ce problème avec une preuve locale contrôlée liée directement au chemin de code Penpot examiné.

Le but n'était pas de toucher une infrastructure tiers. Le but était de prouver la propriété de sécurité exacte :

• exécution de requête de type backend
• suivi de redirection
• pivot réussi vers un point de terminaison interne uniquement
• achèvement dans les mêmes contraintes orientées image que Penpot impose

J'ai construit un validateur Java autonome qui reflétait le comportement pertinent :

• GET côté backend vers une URI fournie par l'appelant
• suivi automatique des redirections
• vérifications d'acceptation d'image basées sur content-type et content-length

J'ai validé deux cas.

Cas 1 : récupération interne directe

Le validateur a demandé :

http://127.0.0.1:7790/internal.png

Résultat observé :

• URI demandée : http://127.0.0.1:7790/internal.png
• URI finale : http://127.0.0.1:7790/internal.png
• statut : 200
• type de contenu : image/png
• artefact écrit avec succès

Cela a prouvé que la logique de récupération de type importation acceptait un point de terminaison d'image interne uniquement directement.

Cas 2 : récupération interne assistée par redirection

Le validateur a ensuite demandé :

http://localhost:7791/redirect-to-internal

Ce point de terminaison a renvoyé une redirection HTTP vers :

http://127.0.0.1:7790/internal.png

Résultat observé :

• URI demandée : http://localhost:7791/redirect-to-internal
• URI finale : http://127.0.0.1:7790/internal.png
• statut : 200
• type de contenu : image/png
• artefact écrit avec succès

L'écouteur interne uniquement a enregistré la requête redirigée.

Cela a prouvé l'affirmation la plus importante :

• l'URL initiale contrôlée par l'attaquant peut différer de la destination finale
• les redirections sont suivies automatiquement
• la récupération finale du backend peut atterrir sur un point de terminaison interne uniquement et toujours réussir

Pourquoi la PoC a été construite de cette façon

La charge utile ici était intentionnellement simple :

• petite réponse PNG valide
• cible de redirection explicite
• écouteur interne uniquement lié à loopback

Cela importait car Penpot ne se contente pas de récupérer des octets arbitraires et de s'arrêter. Il effectue une validation orientée média après la requête.

Donc, la bonne preuve n'était pas :

"le backend peut essayer de se connecter quelque part"

La preuve plus forte était :

"le backend peut être amené à se connecter quelque part d'interne et à terminer la requête avec succès dans les mêmes contraintes de type image attendues par la fonctionnalité"

C'est exactement ce que la validation a démontré.

Pourquoi cela valait la peine d'être signalé

Une réaction courante aux bugs SSRF comme celui-ci est :

"la cible doit toujours renvoyer une image"

Cette observation est vraie mais incomplète.

Elle ne supprime pas la vulnérabilité.

Elle vous indique simplement quelles cibles internes sont les plus directement utiles.

Ce problème permet toujours :

• l'atteignabilité interne d'origine serveur
• le pivotement assisté par redirection dans l'espace loopback ou réseau privé
• l'interaction avec des points de terminaison internes renvoyant des images
• l'abus de confiance réseau depuis la position du serveur Penpot

C'est toujours une véritable rupture de frontière de sécurité.

Surtout dans les environnements auto-hébergés, les services internes existent souvent spécifiquement derrière cette frontière.

Gravité et classification

Ce problème a finalement reçu une gravité Élevée CVSS :

• CWE-918 : Contrefaçon de requête côté serveur (SSRF)
• CVSS :

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Cette classification a du sens.

L'affirmation n'est pas qu'un attaquant non authentifié peut immédiatement compromettre n'importe quel déploiement Penpot à partir de rien.

L'affirmation est que tout éditeur de fichier authentifié normal peut transformer Penpot en une primitive de requête backend vers des destinations internes, y compris l'accès assisté par redirection à des cibles loopback et réseau privé.

Il y a eu quelques discussions sur la gravité lors de la divulgation, principalement autour de :

• les services internes nécessitant une authentification
• le contenu récupéré devant passer la validation d'image
• l'exploitation dépendant de la connaissance de l'infrastructure interne

Ce sont des contraintes justes à discuter.

Mais elles ne suppriment pas le problème central :

• URL contrôlée par l'attaquant
• origine de requête côté serveur
• suivi de redirection
• aucune politique de destination sortante dans le chemin examiné

C'est une vulnérabilité SSRF réelle et défendable.

Analyse du correctif

Le correctif important ici n'est pas une gestion plus stricte de MIME.

Le vrai correctif est la politique de destination sortante.

Une remédiation correcte pour cette classe de bug doit :

1. autoriser uniquement http et https
2. résoudre et rejeter les plages loopback, RFC1918/privées, link-local, multicast, non spécifiées et de service de métadonnées avant la connexion
3. revérifier chaque saut de redirection avec la même politique
4. envisager de désactiver les redirections pour cette fonctionnalité ou de les limiter strictement
5. ajouter une couverture de régression pour :
   • localhost
   • cibles privées directes
   • cas de redirection vers le privé
   • scénarios de type DNS rebinding

C'est la bonne direction de correctif car ce n'était pas un bug d'analyse d'image. C'était un bug de frontière de confiance réseau.

Divulgation

Ce problème a été signalé de manière privée via le flux de signalement de sécurité de GitHub.

Le rapport comprenait :

• une analyse de cause racine au niveau source
• un modèle de validation local solide
• une preuve de pivotement interne basée sur la redirection
• des preuves d'artefact et de journal
• des conseils de remédiation

Les mainteneurs ont confirmé le problème et ont commencé à travailler sur une résolution.

Le problème a ensuite été attribué :

CVE-2026-45806

Ce que ce bug enseigne réellement

La leçon clé ici est simple :

l'importation de médias distants est une frontière de confiance sortante, pas seulement une fonctionnalité de commodité

Beaucoup de développeurs pensent en termes de :

• URL acceptée
• requête réussie
• image passe la validation
• média stocké

Ce sont des détails d'implémentation.

La vraie question de sécurité est :

où le backend est-il autorisé à se connecter au nom d'un utilisateur ?

Si cette question n'est pas répondue explicitement, des fonctionnalités comme l'importation distant deviennent des surfaces SSRF par défaut.

Ce bug renforce également quelque chose d'important dans l'examen SSRF :

• les redirections comptent
• la validation de contenu n'est pas un substitut à la politique réseau
• le SSRF authentifié reste grave lorsqu'il traverse les frontières de confiance internes

C'est le véritable enseignement.

Points clés

• l'importation d'image distante est une véritable frontière de confiance backend
• les fonctionnalités authentifiées peuvent encore exposer des SSRF graves
• le suivi de redirection rend les chemins de récupération sortants beaucoup plus dangereux
• la validation uniquement par image réduit certains chemins d'abus mais ne supprime pas le SSRF
• prouver un chemin de redirection interne réussi est plus fort que de simplement montrer une tentative de connexion échouée
• le bon correctif est la politique de destination sortante, pas une validation de réponse cosmétique

Derniers mots

Cette vulnérabilité ne concernait pas une charge utile flashy.

Il s'agissait de poser la bonne question sur la frontière de confiance.

Penpot permettait à un éditeur de fichier authentifié de fournir une URL d'image distante, et le backend faisait trop confiance à cette URL. La gestion des redirections a fait le reste.

C'est pourquoi cela est devenu CVE-2026-45806.