Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

54 des 55 failles de sécurité déposées par ce compte GitHub n'existaient pas

4 août 2026 à 10:17

JFrog, une société spécialisée dans la sécurité de la chaîne logicielle, a passé au crible les 55 vulnérabilités déposées par un seul compte GitHub. Cinquante-quatre étaient entièrement fabriquées, une seule décrivait un vrai bug.

Six d'entre elles visaient SQLite, la petite base de données embarquée qu'on retrouve dans à peu près tous les téléphones et navigateurs de la planète, avec des scores de gravité affichés jusqu'à 9,8 sur 10. Les quarante-neuf autres s'en prenaient à libraw, une bibliothèque de traitement d'images, et à un module audio pour cartes ESP32.

Les rapports ne résistent pas à une vérification. L'un s'appuie sur une fonction qui n'existe pas dans la version de SQLite qu'il prétend attaquer. Un autre cite les lignes 3555 et 3575 d'un fichier qui n'en compte que 2706.

Ces failles n'ont été bloquées à aucune étape. Elles ont atterri dans le NVD, la base de référence américaine des vulnérabilités, avec un enrichissement fourni par la CISA, l'agence fédérale de cybersécurité, qui a validé les scores critiques au passage. Red Hat a dû redescendre l'une d'elles de 10 sur 10 à 7,6.

Le formulaire public par lequel on déclare une faille ne vérifie pas sérieusement l'identité du déclarant. Aucune étape du processus n'exige de preuve de concept ni la moindre reproduction du bug. Un texte plausible suffit.

Le reste est automatique. La fiche descend dans les bases dérivées, puis dans les scanners que les entreprises font tourner sur leur propre code, et une équipe finit par chercher un correctif à un problème qui n'a jamais existé. MITRE, l'organisme qui attribue ces identifiants, a rejeté le lot le 1er août.

Le NIST, chargé d'analyser ces fiches, avait déjà plus de 27 000 vulnérabilités en attente fin 2025, et un rapport officiel de mai dernier lui reprochait un manque de planification et de décision.

Les mainteneurs de logiciels libres décrochent. Le projet curl a fermé son programme de primes début 2026, après sept ans, son taux de rapports confirmés étant passé de 15 % à moins de 5 % sous le déluge de textes générés par IA.

Daniel Stenberg, qui le maintient, a ensuite fermé le guichet aux signalements du 1er juillet au 3 août. Bref, ce qui faisait tenir le système, c'est que fabriquer un faux rapport crédible demandait du temps à quelqu'un.

Source et visuel : The Register et JFROG

sqlit - Quand y'en a marre de lancer SQL Server Management Studio pour une requête

Par : Korben
17 décembre 2025 à 09:22

Vous aussi vous avez ce truc où vous devez juste faire un petit SELECT rapide sur votre base de données, et là vous lancez un monstre du genre SQL Server Management Studio ou DBeaver, vous attendez que ça se charge pendant 47 ans, que ça bouffe les 2 Go de RAM qu'il vous reste, et tout ça pour une requête de 3 lignes ?

Moi ça m'énerve profondément, j'avoue... Pas le temps, pas la patience !

Heureusement, y'a un dev qui en a eu encore plus marre que moi et qui a pondu sqlit . C'est une interface TUI (Terminal User Interface, je précise...) qui tourne direct dans votre terminal et qui supporte un paquet de bases de données différentes telles que PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, Oracle, DuckDB, CockroachDB, Supabase, Turso... La liste est longue mais en gros, si ça parle SQL, sqlit sait s'y connecter.

Le truc est inspiré de lazygit , un client Git en TUI que beaucoup de devs adorent, ce qui fait qu'on retrouve cette approche "lazy" où l'interface se suffit à elle-même. Comme ça y'a pas besoin de mémoriser 150 raccourcis clavier, puidqu'il y a une aide contextuelle qui s'affiche et qui vous dit quoi faire, comme votre maman quand vous ne l'avez absolument pas sollicitée.

On a donc de l'autocomplétion SQL qui va chercher les noms de tables et de colonnes, un historique des requêtes par connexion (pratique pour retrouver cette requête chelou qu'on avait bidouillée y'a 3 semaines), et même la gestion des tunnels SSH intégrée pour se connecter à des bases distantes. Les utilisateurs de Vim seront contents aussi, car y'a un mode d'édition modal pour naviguer comme dans votre éditeur préféré.

Pour l'installer, c'est hyper simple :

pip install sqlit-tui

Et après vous tapez sqlit dans votre terminal et c'est parti. Les drivers pour chaque type de base de données s'installent à la demande la première fois que vous essayez de vous connecter. Donc pas de dépendances inutiles qui traînent si vous utilisez juste PostgreSQL par exemple.

Y'a aussi un mode CLI si vous voulez scripter vos requêtes :

sqlit query -c "MaConnexion" -q "SELECT * FROM Users" --format csv

Le seul truc naze je trouve, c'est le nom "sqlit" qui ressemble trop à SQLite. Bon courage pour googler des infos dessus... Je sais de quoi je parle, toutes les 2 semaines, y'a une entreprise Korben qui pop en voulant surfer sur mon buzz (ouais j'ai le melon, mdr) et qui passe toutes ses levées de fonds en adwords pour se positionner avant moi sur Google ^^. C'est couillon ^^.

Bref, si vous vivez dans le terminal et que vous en avez marre de lancer des client lourds juste pour un SELECT, c'est vraiment pratique.

❌
❌