Intrusion chez Fakturownia : faut-il un bug bounty ?

Un bug bounty pour un logiciel de facturation rémunère les chercheurs qui démontrent des failles susceptibles d’exposer les données des clients, de compromettre des intégrations ou de modifier des écritures financières. Il repose d’abord sur un programme de divulgation des vulnérabilités (VDP) : un périmètre de test sûr, un canal de signalement et une équipe chargée d’évaluer les rapports et de corriger les failles. L’avis publié par Fakturownia le 29 septembre montre pourquoi ce dispositif compte pour une plateforme qui détient les comptes et les documents d’autres entreprises. Rien ne prouve publiquement qu’une prime aurait empêché cette intrusion.

Qu’a confirmé Fakturownia ?

Fakturownia indique avoir détecté un accès non autorisé à ses serveurs le 28 septembre 2026. Dans son avis public, daté du lendemain, l’entreprise précise qu’une personne non autorisée a exploité une faille de son système et a pu consulter les données des comptes utilisateurs, des contreparties et des documents générés sur la plateforme. L’avis donne la date de détection, pas celle du début de l’intrusion. Il ne décrit pas la faille et ne permet pas d’établir quelle quantité de données a quitté le système.

Selon l’entreprise, l’accès potentiel concerne les données des comptes de tous ses utilisateurs, celles de leurs contreparties et les factures émises avant 2023. La liste comprend les empreintes des mots de passe, les jetons de session, les jetons API et d’intégration émis par Fakturownia, les coordonnées bancaires et les données de paiement, certaines données de factures ainsi que les clés et mots de passe système de l’application. Les empreintes ne sont pas les mots de passe en clair des utilisateurs, mais l’exposition possible de jetons d’accès et de secrets applicatifs exige une réponse distincte. Fakturownia affirme avoir bloqué l’accès non autorisé, commencé à renouveler les clés et les mots de passe, mis en service de nouveaux serveurs et signalé l’incident au CBZC, au CERT Polska et à l’autorité polonaise de protection des données. L’enquête se poursuit.

Fakturownia ajoute que ses constatations actuelles ne montrent aucune compromission des certificats KSeF, des données conservées dans ses intégrations, des données de cartes bancaires ni des factures émises après 2023. L’avis ne précise pas clairement ce qu’il en est des factures émises en 2023. Les jetons d’intégration émis par Fakturownia, dont l’exposition est jugée possible, forment une catégorie de données différente de celles conservées dans les intégrations externes. Il faut distinguer ces deux déclarations.

Zaufana Trzecia Strona rapporte qu’une personne revendiquant l’attaque affirme avoir emporté 6 To de factures. Il s’agit d’une affirmation de l’attaquant présumé, pas d’un volume confirmé par Fakturownia. Le média relaie aussi une méthode d’attaque avancée, mais l’avis de l’entreprise confirme seulement l’exploitation d’une faille de son système. Le déroulement précis de l’attaque, l’identité de son auteur et le volume emporté restent non vérifiés publiquement.

Pourquoi une faille de facturation touche-t-elle plus d’un client ?

Un fournisseur de facturation concentre les données de plusieurs parties. Le compte d’un client peut contenir les accès de ses salariés, les noms et coordonnées de ses contreparties, des numéros de compte bancaire, les lignes des factures et les identifiants reliant ses outils comptables, commerciaux et de paiement. Une faille sur la plateforme du fournisseur peut donc mobiliser de nombreuses entreprises clientes, leurs équipes financières et des personnes qui n’ont jamais ouvert de compte chez lui.

C’est pourquoi un signalement d’accès entre comptes distincts appelle un traitement différent de celui d’un défaut cosmétique. Si un compte de test contrôlé par un chercheur peut lire la facture d’un autre compte de test distinct, le fournisseur doit désigner une personne capable de reproduire la faille, de vérifier si d’autres comptes sont concernés, de la corriger et d’échanger avec la personne qui l’a signalée. Le chercheur doit pouvoir démontrer le problème avec des comptes et des documents qu’il contrôle, sans ouvrir la facture d’un vrai client. Le Top 10 des risques de sécurité des API de l’OWASP distingue les défauts d’autorisation au niveau des objets de ceux de l’authentification. Les deux ont leur place dans le programme de tests d’un logiciel de facturation.

Il en va de même pour les jetons d’accès et les champs liés aux virements. Un rapport pourrait montrer qu’un jeton reste utilisable après sa révocation, qu’un utilisateur peut agir hors du compte qui lui est attribué ou qu’une modification de compte bancaire contourne une protection. Ces exemples illustrent un périmètre possible pour les primes : ils ne décrivent pas des failles constatées dans l’attaque contre Fakturownia. Des tests externes peuvent révéler des défauts dans les fonctions accessibles du produit. Ils ne remplacent ni une conception sûre, ni la revue du code, ni la limitation des privilèges, ni la surveillance, ni la réponse aux incidents.

Que montrent réellement les anciens commentaires sur le bug bounty ?

Les traces publiques soulèvent une question légitime : comment les signalements de sécurité parviennent-ils aux responsables du produit ? L’index du forum de suggestions de Fakturownia affiche une question posée en 2016 sur la création éventuelle d’un programme de bug bounty. Nous n’avons pas pu vérifier la réponse dans la discussion liée. La page publique consacrée à la sécurité explique comment signaler les factures suspectes, l’hameçonnage et les problèmes touchant la page de connexion. Dans la version que nous avons consultée, elle ne définit toutefois ni périmètre de test des vulnérabilités, ni sphère de sécurité (Safe Harbor), ni délai de réponse visé, ni règles de rémunération. Cela ne permet pas de conclure que Fakturownia ne dispose d’aucun processus privé de signalement.

Dans des commentaires LinkedIn qui nous ont été transmis après l’incident, deux professionnels disent avoir signalé des problèmes à Fakturownia au cours des années précédentes. L’un précise que certaines démonstrations de bugs portaient sur les revenus du fournisseur plutôt que sur la sécurité des données clients. Nous n’avons vu ni les rapports, ni les réponses de l’entreprise, ni de lien entre ces propos et l’intrusion actuelle. Ces commentaires soulèvent une question sur la conception du programme, mais ne prouvent pas qu’une vulnérabilité signalée a été ignorée puis exploitée.

Que doit-il se passer lorsqu’un chercheur signale un abus concret qui n’entre pas dans une liste étroite de vulnérabilités techniques ? Une faille de facturation ou de remise n’est pas automatiquement une faille de sécurité. Elle doit néanmoins parvenir à une personne qui peut en mesurer l’impact, décider si elle relève du bug bounty et répondre au chercheur. Un fournisseur qui écarte un tel rapport sans réponse perd une information utile, même si son programme de sécurité ne rémunère pas cette catégorie de problèmes.

À qui adresser un signalement concernant un logiciel de facturation ?

Un programme utile précise qui prendra la prochaine décision, au-delà d’une simple adresse e-mail. Les recommandations du NIST préconisent un processus formel pour recevoir, évaluer, traiter les signalements et communiquer à leur sujet. L’équipe de sécurité peut recevoir les rapports, mais elle doit pouvoir les transmettre aux responsables techniques, financiers ou produit capables d’agir.

Dans chaque cas, le chercheur doit recevoir un accusé de réception, des nouvelles sur le traitement et une décision motivée. Un rapport valide ne devrait pas disparaître parce qu’une équipe y voit un problème produit et une autre un problème de sécurité. Le fournisseur peut adopter des règles de rémunération différentes selon la catégorie, mais il doit publier cette distinction et assurer la transmission du rapport.

Que publier avant de proposer des primes ?

Publiez un programme de divulgation des vulnérabilités (VDP) avec un contact facile à trouver, le périmètre des applications et des API que le fournisseur contrôle, une sphère de sécurité (Safe Harbor) pour les tests de bonne foi, les délais de réponse attendus et une voie de traitement pour les cas incertains. Un fichier security.txt peut indiquer aux chercheurs le contact et la politique ; le fichier lui-même n’autorise aucun test. Le guide de mise en place d’un VDP détaille les autres étapes.

Pour un logiciel de facturation, prévoyez deux comptes de test distincts contrôlés par le chercheur et des documents fictifs. Un seul compte peut contenir plusieurs entreprises : créer deux fiches d’entreprise ne suffit donc pas nécessairement à tester la séparation entre comptes. Demandez aux chercheurs d’arrêter les tests s’ils rencontrent de vraies factures, des coordonnées bancaires ou des identifiants, puis de signaler le problème avec le minimum de preuves expurgées. Interdisez les exportations massives, les modifications de paiement, les tests destructeurs, l’ingénierie sociale et les tests de charge. Ne désignez que des systèmes que le fournisseur contrôle ou qu’il est autorisé à faire tester. La politique actuelle de Visma illustre un canal de signalement large, assorti d’une sphère de sécurité (Safe Harbor), et un bug bounty rémunéré plus restreint, réservé aux actifs expressément désignés.

Financez ensuite un bug bounty au périmètre défini lorsque l’équipe peut valider davantage de rapports, corriger les problèmes retenus et respecter ses décisions de rémunération. Le guide de l’OWASP sur la divulgation rappelle qu’une prime augmente à la fois le nombre de signalements et le travail nécessaire pour les traiter. Rémunérez l’impact démontré, pas l’étiquette donnée au rapport ; publiez les fourchettes et les règles applicables aux doublons pour que le chercheur sache à quoi s’attendre. Le guide des niveaux de prime en décrit le fonctionnement.

Aucune source publique n’établit qu’un chercheur externe avait découvert la faille exploitée chez Fakturownia, qu’il aurait pu la tester sans risque ou qu’il avait tenté de la signaler. On ne peut donc pas affirmer qu’un bug bounty rémunéré aurait empêché cet incident. Un tel programme peut donner aux prochains signalements de meilleures chances d’atteindre une équipe responsable avant qu’un acteur malveillant exploite les failles.

Que doivent faire et demander les clients de Fakturownia ?

Dans son avis du 29 septembre, Fakturownia recommande de changer le mot de passe du compte et tout mot de passe réutilisé ailleurs, de sécuriser la messagerie associée, d’activer l’authentification à deux facteurs et de vérifier le numéro de compte bancaire et la liste des utilisateurs dans les paramètres du compte. L’entreprise met aussi en garde contre les messages et les appels usurpant l’identité de banques, d’administrations, de Fakturownia ou de contreparties. Telles sont ses recommandations publiques actuelles pendant qu’elle détermine qui doit être averti. Demandez-lui directement où en sont les jetons de session, d’API ou d’intégration que vous utilisez : son avis les cite parmi les données potentiellement accessibles, sans fournir de procédure complète de renouvellement pour les clients.

Demandez ensuite quelle est sa procédure de divulgation. Un chercheur sans compte peut-il trouver un contact de sécurité ? La politique autorise-t-elle les tests sur les systèmes contrôlés par le fournisseur tout en protégeant les données des clients ? Un rapport sur l’accès à la facture d’un autre compte, un jeton, des coordonnées bancaires ou une règle de facturation parviendra-t-il à une personne capable de corriger le problème et de répondre au chercheur ? Ces questions concernent les logiciels comptables, les plateformes de facturation et notre propre catégorie de logiciels liés à KSeF. Notre article sur la sphère de sécurité (Safe Harbor) traite des termes de l’autorisation ; le guide sur le périmètre des tests distingue les actifs du fournisseur des systèmes de ses clients.

Comment Kit accompagne-t-il le traitement d’un signalement jusqu’à la décision ?

Kit aide un fournisseur à publier un programme de divulgation au périmètre défini et un contact security.txt facile à trouver. Les chercheurs peuvent déposer leurs rapports sur le portail ; l’équipe peut désigner un responsable, suivre les délais de réponse, discuter des failles et consigner une éventuelle décision de prime. Kit suit la transmission pour paiement, tandis que le fournisseur verse lui-même la somme avec son propre prestataire.

Un premier test suffit : déposez un rapport fictif sur un accès entre comptes distincts et suivez-le, de sa réception jusqu’à la décision de l’équipe technique et à la réponse au chercheur. Vous verrez si un véritable signalement serait entendu. Kit organise ce parcours ; le fournisseur reste responsable de l’enquête, de la correction et de la protection de ses clients.