rootdirective-sec/cve-2026-46645-analysis-lab
Laboratoire basé sur Docker pour reproduire CVE-2026-46645, un contournement d'autorisation dans le point de terminaison ajax_lookup de SQLAdmin. Inclut des cibles vulnérables et corrigées, un script PoC, et des étapes de reproduction manuelle avec curl pour la recherche en sécurité et l'éducation.
Ce référentiel contient un laboratoire Docker local pour reproduire CVE-2026-46645, une vulnérabilité de contournement d'autorisation affectant le point de terminaison ajax_lookup de SQLAdmin.
SQLAdmin est une interface d'administration pour les modèles SQLAlchemy dans les applications Starlette et FastAPI. Le comportement vulnérable se produit lorsqu'une application restreint une ModelView avec is_accessible(request), mais que la route ajax_lookup de SQLAdmin n'applique pas la même décision de contrôle d'accès avant de renvoyer les résultats de la recherche.
Ce laboratoire compare deux versions de SQLAdmin :
| Service | Version SQLAdmin | Objectif | URL |
|---|---|---|---|
vuln | 0.25.0 | Cible vulnérable | http://127.0.0.1:8001 |
patched | 0.25.1 | Cible de comparaison corrigée | http://127.0.0.1:8002 |
La chaîne de vulnérabilité démontrée est :```text Authenticated low-privileged user → restricted SQLAdmin ModelView → ModelView.is_accessible(request) returns False → user directly requests the ajax_lookup endpoint → SQLAdmin 0.25.0 returns relationship lookup data → SQLAdmin 0.25.1 blocks the same request with HTTP 403
Le laboratoire utilise intentionnellement un modèle de données simple `Report` / `SecretProject` pour rendre le contournement d'autorisation facile à comprendre. Ces noms de modèles ne sont pas la cause profonde de la vulnérabilité. Ils sont uniquement utilisés pour créer une condition de reproduction contrôlée.
Ce laboratoire est conçu uniquement pour la recherche locale contrôlée, la compréhension au niveau du code source et la démonstration de portfolio.
## Faits vérifiés
| Affirmation | Preuve | Comment vérifier dans ce laboratoire |
| --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Le point de terminaison `ajax_lookup` de SQLAdmin est le composant affecté. | L'avis public décrit le format du point de terminaison affecté comme `GET /{identity}/ajax/lookup?name=<field>&term=<query>`. | Exécutez le PoC et observez les requêtes vers `/admin/report/ajax/lookup?name=project&term=Secret`. |
| SQLAdmin `0.25.0` est utilisé comme cible de comparaison vulnérable. | Le laboratoire installe `sqladmin==0.25.0` dans le conteneur `vuln`. | Exécutez `docker compose exec -T vuln python -m pip show sqladmin`. |
| SQLAdmin `0.25.1` est utilisé comme cible de comparaison corrigée. | L'avis public et les notes de version identifient `0.25.1` comme la version corrigée. | Exécutez `docker compose exec -T patched python -m pip show sqladmin`. |
| La cause profonde se trouve dans la route `Admin.ajax_lookup()` en amont de SQLAdmin. | Le correctif ajoute l'authentification manquante et l'application de `is_accessible(request)` à `ajax_lookup()`. | Inspectez `Admin.ajax_lookup()` dans les deux conteneurs avec les commandes de ce README. |
| Le laboratoire crée un `ModelView` restreint. | `ReportAdmin.is_accessible(request)` renvoie intentionnellement `False`. | Inspectez `app/main.py`. |
| Le PoC utilise une session authentifiée. | Le PoC se connecte d'abord à `/admin/login`, conserve le cookie de session, puis demande `ajax_lookup`. | Exécutez `python3 poc/poc.py --base-url http://127.0.0.1:8001`. |
| Le signal de vulnérabilité est l'exposition de données. | SQLAdmin `0.25.0` renvoie HTTP 200 et des résultats de recherche JSON depuis une vue restreinte. | La cible vulnérable doit renvoyer `Secret Project Alpha` et `Secret Project Beta`. |
| Le signal corrigé est le refus d'accès. | SQLAdmin `0.25.1` renvoie HTTP 403 pour la même requête authentifiée. | La cible corrigée doit renvoyer `403 Forbidden`. |
## Hypothèses et inconnues
Ce laboratoire utilise `sqladmin==0.25.0` comme base de référence vulnérable et `sqladmin==0.25.1` comme base de référence corrigée.
Le laboratoire se concentre sur la condition de contournement d'autorisation où :```text
A user is authenticated,
the target ModelView is not accessible,
but ajax_lookup is requested directly.
Le laboratoire ne tente pas de reproduire tous les modèles de déploiement possibles de SQLAdmin. Il crée intentionnellement une petite application Starlette avec une vue d'administration restreinte afin que la différence de comportement entre les versions vulnérable et corrigée soit facile à vérifier.
Les modèles Report et SecretProject sont des objets propres au laboratoire. Ils ne font pas partie de SQLAdmin lui-même.
La PoC ne tente pas d'escalade de privilèges, de modification de données, de vol de session, de rappels externes, de persistance ou d'attaques contre des systèmes hors laboratoire.
La cause racine se trouve dans la route Admin.ajax_lookup() en amont de SQLAdmin, et non dans le code de l'application de ce laboratoire.
SQLAdmin permet aux développeurs de restreindre l'accès aux vues d'administration en surchargeant :```python ModelView.is_accessible(request)
Les autres routes d'administration sont censées appliquer cette décision de contrôle d'accès avant d'autoriser la poursuite de la requête. Par exemple, les routes telles que list, create, details, delete, edit et export vérifient si la requête courante est autorisée à accéder au `ModelView` cible.
La route vulnérable `ajax_lookup` n'a pas appliqué la même décision de contrôle d'accès.
Le point de terminaison `ajax_lookup` est utilisé par la fonctionnalité `form_ajax_refs` de SQLAdmin pour charger dynamiquement les valeurs de relations. Son format de point de terminaison est :```text
/admin/<identity>/ajax/lookup?name=<field>&term=<query>
Dans la version vulnérable, ajax_lookup() résout le ModelView cible, lit le nom du champ de recherche et le terme de recherche depuis la chaîne de requête, puis appelle le chargeur AJAX et renvoie les résultats JSON. L'étape de sécurité manquante est qu'elle ne vérifie pas d'abord si la demande actuelle est autorisée à accéder à ce ModelView.
L'impact sur la sécurité est qu'un utilisateur authentifié peut être bloqué pour accéder à une vue d'administration restreinte via les routes normales de l'interface utilisateur, mais peut toujours demander directement le point de terminaison de recherche AJAX pour cette vue et recevoir des données de recherche de relations.
SQLAdmin 0.25.1 corrige cela en imposant le contrôle d'accès à l'intérieur de ajax_lookup(). La route corrigée vérifie model_view.is_accessible(request) et renvoie HTTP 403 lorsque la vue cible n'est pas accessible.