Ein **Prämienprogramm für Sicherheitslücken in Rechnungssoftware** belohnt Forscher für bestätigte Schwachstellen, durch die Kundendaten offengelegt, Integrationen kompromittiert oder Finanzdaten verändert werden könnten. Dafür braucht es zuerst eine Richtlinie zur Meldung von Schwachstellen (VDP): einen klaren Rahmen für sichere Tests, einen Meldeweg und ein Team, das eingehende Meldungen prüft und die Probleme behebt. [Fakturownias Mitteilung zum Vorfall vom 29. September](https://fakturownia.pl/incydent) zeigt, warum ein solcher Meldeweg für eine Plattform mit Konten und Dokumenten anderer Unternehmen wichtig ist. Es gibt keinen öffentlichen Beleg dafür, dass ein Prämienprogramm diesen Angriff verhindert hätte.

## Was hat Fakturownia bestätigt?

Fakturownia gibt an, am **28. September 2026 unbefugten Zugriff auf seine Server festgestellt** zu haben. Laut der am Folgetag veröffentlichten [Mitteilung](https://fakturownia.pl/incydent) nutzte eine unbefugte Person eine Schwachstelle im System aus und konnte Daten von Nutzerkonten, Geschäftspartnern sowie auf der Plattform erstellte Dokumente einsehen. Genannt wird der Tag der Entdeckung, nicht der Beginn des Zugriffs. Die Mitteilung beschreibt weder die Schwachstelle näher noch belegt sie, wie viele Daten das System verlassen haben.

Nach Angaben des Unternehmens könnte der Zugriff Kontodaten sämtlicher Nutzer, Daten ihrer Geschäftspartner und Rechnungen **aus der Zeit vor 2023** betroffen haben. Die Liste umfasst Passwort-Hashes, Sitzungstoken, von Fakturownia ausgestellte API- und Integrationstoken, Bankverbindungen und Zahlungsdaten, einen Teil der Rechnungsdaten sowie Anwendungsschlüssel und Systempasswörter. Passwort-Hashes sind keine Klartextpasswörter der Nutzer. Der mögliche Zugriff auf Token und Anwendungsschlüssel erfordert aber eine eigene Reaktion. Fakturownia erklärt, den unbefugten Zugriff gesperrt, mit dem Austausch von Schlüsseln und Passwörtern begonnen, neue Server in Betrieb genommen und den Vorfall an CBZC, CERT Polska sowie die polnische Datenschutzbehörde gemeldet zu haben. Die Untersuchung läuft noch.

Fakturownia erklärt außerdem, dass nach bisherigem Kenntnisstand weder KSeF-Zertifikate noch Daten, die in seinen Integrationen gespeichert sind, Zahlungskartendaten oder Rechnungen **aus der Zeit nach 2023** kompromittiert wurden. Rechnungen *aus dem Jahr 2023* spricht die Mitteilung nicht eindeutig an. Die möglicherweise offengelegten, von Fakturownia ausgestellten Integrationstoken sind eine andere Datenkategorie als Daten, die in externen Integrationen gespeichert sind. Beides sollte nicht gleichgesetzt werden.

Laut [Zaufana Trzecia Strona](https://zaufanatrzeciastrona.pl/post/nowe-wlamanie-fingerprinta-ofiara-firma-fakturowniapl/) behauptet eine Person, die sich zu dem Angriff bekennt, **6 TB an Rechnungen** entwendet zu haben. Das ist eine Behauptung der angreifenden Person, keine von Fakturownia bestätigte Datenmenge. Der Artikel gibt auch eine mögliche Angriffsmethode wieder. Die Mitteilung des Unternehmens bestätigt jedoch lediglich, dass eine Schwachstelle im System ausgenutzt wurde. Der genaue Angriffsweg, die Identität der angreifenden Person und die entwendete Datenmenge sind öffentlich weiterhin nicht verifiziert.

## Warum kann eine einzige Schwachstelle viele Kunden treffen?

Ein Anbieter von Rechnungssoftware bündelt Daten mehrerer Beteiligter. In einem Kundenkonto können Zugänge von Mitarbeitenden, Namen und Kontaktdaten von Geschäftspartnern, Bankverbindungen, Rechnungspositionen sowie Zugangsdaten für Buchhaltungs-, Handels- und Zahlungssysteme liegen. Eine Schwachstelle in der Plattform des Anbieters kann deshalb viele Kundenunternehmen, deren Finanzteams und auch Personen betreffen, die dort nie selbst ein Konto eröffnet haben.

Eine Meldung über **Zugriff über Kontogrenzen hinweg** muss daher anders behandelt werden als ein kosmetischer Fehler. Kann ein Testkonto des Forschers die Rechnung eines zweiten, eigenständigen Testkontos lesen, braucht der Anbieter eine zuständige Person: Sie muss den Befund reproduzieren, weitere betroffene Zugriffsgrenzen prüfen, den Fehler beheben und mit dem Forscher kommunizieren. Der Forscher muss die Schwachstelle mit selbst kontrollierten Konten und Dokumenten nachweisen können, ohne eine echte Kundenrechnung zu öffnen. Die [API Security Top 10 von OWASP](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) führen fehlerhafte Objektberechtigungen und Authentifizierung als getrennte API-Risiken auf. Beides gehört in den Testplan einer Rechnungsplattform.

Dasselbe gilt für Zugriffstoken und Angaben, die Zahlungen lenken. Eine Meldung könnte zeigen, dass ein Token nach dem Widerruf weiter funktioniert, ein Nutzer außerhalb des ihm zugewiesenen Kontos handeln kann oder eine Änderung der Bankverbindung eine Schutzmaßnahme umgeht. Das sind Beispiele für einen möglichen Prämienrahmen, **keine Erkenntnisse über den Angriff auf Fakturownia**. Externe Tests können Fehler in erreichbaren Produktfunktionen aufdecken. Sie ersetzen weder sichere Architektur und Code-Reviews noch eingeschränkte Zugriffsrechte, Überwachung und Reaktion auf Sicherheitsvorfälle.

## Was belegen die älteren Kommentare zu Bug-Bountys?

Die öffentlich sichtbaren Hinweise werfen die Frage auf, wie Sicherheitsmeldungen die zuständigen Produktteams erreichen. Im [Index des Fakturownia-Ideenforums](https://sugester.fakturownia.pl/all?page=217&sort=newest) findet sich eine **Frage aus dem Jahr 2016**, ob das Unternehmen ein Bug-Bounty-Programm plane. Die Antwort im verlinkten Thread konnten wir nicht verifizieren. Die [öffentliche Sicherheitsseite](https://fakturownia.pl/bezpieczenstwo) erklärt, wie Besucher verdächtige Rechnungen, Phishing und Probleme mit der Anmeldeseite melden können. Die von uns geprüfte Seite nennt aber keinen Rahmen für Schwachstellentests, keine Safe-Harbor-Regeln, keine Antwortfrist und keine Prämienregeln. Daraus lässt sich nicht ableiten, ob Fakturownia einen privaten Meldeprozess für Sicherheitslücken hat.

In LinkedIn-Kommentaren, die nach dem Vorfall mit uns geteilt wurden, berichten zwei Fachleute, sie hätten Fakturownia bereits vor Jahren auf Probleme hingewiesen. Einer schreibt, einige seiner Proof-of-Concepts hätten eher die Einnahmen des Anbieters als die Sicherheit von Kundendaten betroffen. **Wir kennen weder die Meldungen noch die Antworten des Unternehmens. Auch ein Zusammenhang zwischen diesen Aussagen und dem aktuellen Vorfall ist nicht belegt.** Die Kommentare werfen eine Frage zur Gestaltung des Meldeprozesses auf. Sie belegen nicht, dass eine gemeldete Schwachstelle ignoriert und später ausgenutzt wurde.

Was sollte geschehen, wenn jemand einen praktisch ausnutzbaren Missbrauch meldet, der nicht in eine enge Liste technischer Sicherheitslücken passt? Ein Schlupfloch bei Abrechnung oder Rabatten ist nicht automatisch eine Sicherheitslücke. Trotzdem muss die Meldung jemanden erreichen, der die Auswirkungen beurteilt, über eine mögliche Prämie entscheidet und dem Finder antwortet. **Ein Anbieter, der eine solche Meldung stillschweigend fallen lässt, verliert einen wertvollen Hinweis**, auch wenn sein Sicherheitsprogramm für diese Art von Fehler keine Prämie zahlt.

## An wen sollte eine Meldung über Rechnungssoftware gehen?

Ein gutes Programm legt die **nächste Entscheidung** fest, nicht nur eine E-Mail-Adresse. Die [NIST-Empfehlungen zur Offenlegung](https://www.nist.gov/publications/recommendations-federal-vulnerability-disclosure-guidelines) sehen einen formalen Prozess vor, um Meldungen entgegenzunehmen, zu bewerten, zu bearbeiten und darüber zu kommunizieren. Das Sicherheitsteam kann die Meldungen zuerst annehmen. Es muss sie aber an die zuständigen Personen in Entwicklung, Finanzen oder Produkt weiterleiten können, die handeln können.

| Der Finder weist nach | Der Anbieter weist zu | Für die Prämienentscheidung zählt |
|---|---|---|
| Zugriff von einem Testkonto des Forschers auf eine Rechnung in einem zweiten, eigenständigen Testkonto | Sicherheitsteam und Team für Kontoberechtigungen | Ist die Kontogrenze durchbrochen? Welche weiteren Zugriffswege sind betroffen, und welche Kundendaten könnten offengelegt werden? |
| Ein Token bleibt nach dem Widerruf nutzbar oder gewährt mehr Zugriff als vorgesehen | Sicherheitsteam und Verantwortliche für Integrationen | Gibt es einen praktisch nutzbaren Weg zu unbefugtem Zugriff? Wie lassen sich betroffene Token ungültig machen? |
| Unbefugte Änderung eines Zahlungsempfängers oder Bankkontos | Sicherheitsteam, Zahlungsbereich und Betrugsabwehr | Könnte Geld umgeleitet werden? Wie lässt sich die Änderung nachweisen, ohne echte Zahlungen zu berühren? |
| Wiederholbarer Missbrauch von Rabatten, Abrechnung oder Guthaben | Produkt und Finanzen, bei betroffenen Zugriffsrechten auch das Sicherheitsteam | Welcher Schaden oder Missbrauch ist nachgewiesen? Deckt das Prämienprogramm ihn ab, oder braucht es eine gesonderte Entscheidung? |

Für jede dieser Meldungen braucht der Finder eine Eingangsbestätigung, eine Statusmeldung und eine begründete Entscheidung. Eine gültige Meldung darf nicht verschwinden, weil ein Team sie für ein Produktproblem und ein anderes für ein Sicherheitsproblem hält. Der Anbieter kann für jede Kategorie eigene Prämienregeln festlegen. Er sollte die Abgrenzung aber veröffentlichen und die Übergabe zwischen den Teams verantworten.

## Was sollte der Anbieter vor einem Prämienprogramm veröffentlichen?

Zuerst gehört eine **Richtlinie zur Meldung von Schwachstellen (VDP)** dazu: mit einem leicht auffindbaren Kontakt, dem Geltungsbereich der eigenen Anwendung und APIs, Safe-Harbor-Regeln für gutgläubige Tests, erwarteten Antwortzeiten und einem Weg für unklare Fälle. Eine [`security.txt`-Datei](https://www.rfc-editor.org/rfc/rfc9116.html) kann auf den Kontakt und die Richtlinie verweisen. Die Datei allein erlaubt keine Tests. Der [Leitfaden zum Einrichten einer VDP](/blog/how-to-set-up-vulnerability-disclosure-program) beschreibt die weiteren Schritte.

Für Rechnungssoftware braucht es **zwei getrennte Testkonten, die der Forscher selbst kontrolliert**, sowie synthetische Dokumente. In einem einzigen Konto können mehrere Unternehmen verwaltet werden. Zwei Firmeneinträge im selben Konto reichen deshalb womöglich nicht aus, um die Kontogrenze zu prüfen. Forscher sollen Tests abbrechen, sobald sie auf echte Rechnungen, Bankdaten oder Zugangsdaten stoßen, und dann nur die nötigen geschwärzten Belege melden. Massenexporte, Zahlungsänderungen, zerstörerische Tests, Social Engineering und Lasttests sollten untersagt sein. Der Geltungsbereich darf nur Systeme nennen, die dem Anbieter gehören oder für deren Prüfung er eine Erlaubnis hat. Die [aktuelle Richtlinie von Visma](https://www.visma.com/trust-centre/responsible-disclosure) zeigt einen breiten Meldeweg mit Safe-Harbor-Regeln und ein engeres, bezahltes Prämienprogramm für ausdrücklich genannte Systeme.

Danach kann der Anbieter **ein bezahltes Prämienprogramm mit klarem Geltungsbereich** finanzieren, wenn sein Team zusätzliche Meldungen prüfen, bestätigte Fehler beheben und Prämienzusagen einhalten kann. Die [OWASP-Empfehlungen zur Offenlegung](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) warnen, dass ein Prämienprogramm sowohl die Zahl der Meldungen als auch den Aufwand für ihre Bearbeitung erhöht. Bezahlt werden sollte die nachgewiesene Auswirkung, nicht das Etikett der Meldung. Veröffentlichte Prämienstufen und Regeln für Duplikate schaffen klare Erwartungen. Unser [Leitfaden zu Prämienstufen](/blog/bug-bounty-reward-tiers-researchers-trust-hackerone-cuts) erklärt die Einzelheiten.

Keine öffentliche Quelle belegt, dass ein externer Forscher die bei Fakturownia ausgenutzte Schwachstelle zuerst entdeckt hat, sie gefahrlos hätte testen können oder sie zu melden versuchte. Ein bezahltes Programm kann deshalb nicht als Maßnahme gelten, die diesen Vorfall verhindert hätte. Es kann aber künftigen Funden eine bessere Chance geben, **vor** dem Missbrauch durch Kriminelle ein zuständiges Team zu erreichen.

## Was sollten Fakturownia-Kunden jetzt tun und fragen?

In seiner **Mitteilung vom 29. September** [empfiehlt Fakturownia](https://fakturownia.pl/incydent), das Kontopasswort und überall sonst verwendete gleiche Passwörter zu ändern, das verknüpfte E-Mail-Konto abzusichern, die Zwei-Faktor-Authentifizierung einzuschalten und die Bankverbindung sowie die Nutzerliste in den Kontoeinstellungen zu prüfen. Das Unternehmen warnt außerdem vor Nachrichten und Anrufen, in denen sich jemand als Bank, Behörde, Fakturownia oder Geschäftspartner ausgibt. Das sind seine derzeit öffentlich genannten Empfehlungen, während es klärt, wen es benachrichtigen muss. Fragen Sie Fakturownia direkt nach dem Status Ihrer Sitzungs-, API- und Integrationstoken. Die öffentliche Mitteilung nennt sie als möglicherweise zugänglich, enthält aber keine vollständige Anleitung für Kunden zum Austausch dieser Token.

Fragen Sie anschließend nach dem Meldeprozess des Anbieters. Findet ein unabhängiger Forscher ohne Anmeldung einen Sicherheitskontakt? Erlaubt die Richtlinie Tests an Systemen des Anbieters und schützt zugleich Kundendaten? Erreicht eine Meldung über fremde Rechnungen, Token, Bankdaten oder Abrechnungsregeln jemanden, der den Fehler beheben und dem Finder antworten kann? Diese Fragen gelten für Buchhaltungssysteme, Abrechnungsplattformen und auch für unsere eigene Kategorie KSeF-bezogener Software. Der [Artikel zu Safe Harbor](/blog/safe-harbor-legal-threats-security-researchers-vdp) behandelt die Erlaubnis zu Tests. Der [Leitfaden zum Geltungsbereich](/blog/security-scanning-asset-scope-authorization) erklärt die Grenze zwischen Systemen des Anbieters und denen seiner Kunden.

## Wie unterstützt Kit den Weg von der Meldung zur Entscheidung?

Mit Kit kann ein Anbieter ein [Meldeprogramm mit klarem Geltungsbereich](/docs/configuring-your-program) und einen auffindbaren [Kontakt über `security.txt`](/docs/security-txt-setup) veröffentlichen. Forscher können Meldungen über das [Forscherportal](/docs/the-researcher-portal) einreichen. Das Team kann eine zuständige Person zuweisen, Antwortfristen verfolgen, Befunde besprechen und optional über eine Prämie entscheiden. Kit dokumentiert die Übergabe für die Auszahlung; der Anbieter überweist das Geld über seinen eigenen Zahlungsdienstleister.

Ein erster sinnvoller Test ist einfach: Reichen Sie eine Meldung über einen synthetischen Zugriff über Kontogrenzen hinweg ein und verfolgen Sie sie vom Eingang bis zur technischen Entscheidung und Antwort. So sehen Sie, ob ein echter Finder Gehör findet. Kit organisiert diesen Ablauf. Der Anbieter muss die Schwachstelle weiterhin selbst untersuchen, beheben und seine Kunden schützen.