La validation du chemin d'accès de `FilesystemBridge` de @tinacms/graphql peut être contournée via des liens symboliques ou des jonctions

## Résumé `@tinacms/graphql` utilise des vérifications de confinement de chemin d'accès basées sur des chaînes de caractères dans `FilesystemBridge` : - `path.resolve(path.join(baseDir, filepath))` - `startsWith(resolvedBase + path.sep)` Cela bloque la traversée simple `../`, mais ne résout pas les cibles des liens symboliques ou des jonctions. Si un lien symbolique/jonction existe déjà sous la racine de contenu autorisée, un chemin d'accès tel que `content/posts/pivot/owned.md` est toujours considéré comme "à l'intérieur" de la base, même si la cible réelle du système de fichiers peut être en dehors de celle-ci. Par conséquent, `FilesystemBridge.get()`, `put()`, `delete()` et `glob()` peuvent fonctionner sur des fichiers en dehors de la racine prévue. ## Détails La validation actuelle du pont est la suivante : ```ts function assertWithinBase(filepath: string, baseDir: string): string { const resolvedBase = path.resolve(baseDir); const resolved = path.resolve(path.join(baseDir, filepath)); if ( resolved !== resolvedBase && !resolved.startsWith(resolvedBase + path.sep) ) { throw new Error( `Path traversal detected: "${filepath}" escapes the base directory` ); } return resolved; } ``` Mais le pont effectue ensuite de véritables E/S de système de fichiers sur le chemin d'accès résultant : ```ts public async get(filepath: string) { const resolved =