E-Rechnung empfangen: KoSIT schließt Lücke in der Anzeige von XRechnungen

Eine Lücke im Baustein für die Rechnungsansicht

Eine E-Rechnung im Format XRechnung ist für Menschen zunächst kaum lesbar. Sie kommt als XML-Datei an, einer strukturierten Textdatei voller Feldnamen und Kennungen. Damit im Rechnungseingang trotzdem eine Rechnung auf dem Bildschirm erscheint, wandelt die Software die Datei in eine lesbare Ansicht um. Für diesen Schritt stellt die Koordinierungsstelle für IT-Standards (KoSIT) in Bremen in einem öffentlichen Projekt einen Baustein bereit: die XRechnung-Visualisierung.

In diesem Baustein hat die KoSIT eine Sicherheitslücke geschlossen. Die korrigierte Fassung heißt v2026-10-13 und ist am 13. Oktober 2026 erschienen. Am 16. Oktober 2026 folgte auf der KoSIT-Seite xeinkauf.de die Meldung „Hotfix XRechnung Visualisierung“. Dort steht: „Neues Hotfix: die Sicherheit vor Javascript Code Injection in der HTML-Darstellung von XRechnungen wurde erhöht.“ Code Injection bedeutet, dass über präparierte Daten Programmcode in eine Anwendung gelangt, der dort nicht hingehört und ausgeführt werden kann.

Ob Ihr Betrieb betroffen ist, kann dieser Beitrag nicht beantworten. Keine der Quellen nennt ein Rechnungs-, Buchhaltungs- oder ERP-Programm, das den Baustein verwendet. ERP steht für Enterprise Resource Planning: Software, die Einkauf, Lager, Verkauf und Buchhaltung eines Betriebs in einem System zusammenführt. Was der Beitrag leisten kann: erklären, was hinter der Meldung steckt, und Ihnen die Fragen an die Hand geben, die Sie Ihrem Softwareanbieter stellen.

Was der Baustein ist und was nicht

Die XRechnung-Visualisierung ist kein eigenes Programm, das Sie installieren. Laut der Projektbeschreibung der KoSIT besteht sie aus XSL-Transformationen, also aus Umwandlungsregeln, die eine XML-Datei in eine andere Form bringen. Sie nehmen eine XRechnung in einer ihrer beiden technischen Schreibweisen (UBL oder CII) entgegen und erzeugen über ein Zwischenformat entweder eine HTML-Ansicht, wie sie ein Browser darstellt, oder eine PDF-Datei. Die KoSIT schreibt dazu: „These components are not software solutions but merely represent optional building blocks in 3rd party software.“ Gemeint ist: keine fertige Software, sondern optionale Bausteine, die andere Hersteller in ihre Programme einbauen können.

Zwei weitere Punkte aus derselben Beschreibung helfen im Alltag. Erstens verpflichtet der Standard XRechnung niemanden, diese Bausteine zu verwenden. Ein Anbieter kann seine Anzeige auch auf anderem Weg bauen. Zweitens ist laut KoSIT nur die XML-Datei die Originalrechnung. Die Visualisierung ist keine gültige XRechnung und nicht zur Archivierung gedacht. Was Sie im Einzelnen aufbewahren müssen, klärt Ihre Steuerberatung. Für diesen Beitrag genügt: Die Ansicht am Bildschirm ist eine Lesehilfe, nicht die Rechnung selbst.

Welche Fristen für den Empfang und den Versand von E-Rechnungen gelten, erklärt unser Beitrag zur E-Rechnung zwischen Unternehmen (B2B).

Wo die Lücke saß

Die Einzelheiten stehen in Ticket #186 im öffentlichen Projekt der KoSIT auf GitLab, einer Plattform, auf der Softwareprojekte ihren Code und ihre Fehlermeldungen verwalten. Das Ticket trägt den Titel „JavaScript Security issue w.r.t to filenames for embedded (attached) documents“ und wurde am 8. Oktober 2026 angelegt.

Betroffen war laut Ticket die Datei xrechnung-html.xsl, also der Teil, der die HTML-Ansicht erzeugt. Es geht um Angaben zu rechnungsbegründenden Unterlagen, die einer E-Rechnung beigefügt sein können. Die Kürzel BG und BT bezeichnen im Standard Gruppen und einzelne Felder einer Rechnung; die Gruppe für diese Unterlagen heißt BG-24, im Original „Additional supporting documents“. Drei Angaben daraus hat die Ansicht laut Ticket direkt in JavaScript eingesetzt: die Kennung der Unterlage (BT-122), den MIME-Code, der den Dateityp angibt, und den Dateinamen des angehängten Dokuments (BT-125). JavaScript ist die Programmiersprache, die Browser ausführen, etwa für Schaltflächen und Reiter auf einer Webseite.

Genau dort lag das Problem. Im Ticket heißt es: „An apostrophe in BT-122 or in the filename allows JavaScript to be injected.“ Ein einfaches Hochkomma in der Kennung oder im Dateinamen genügte also, um eigenen Code in die Ansicht zu schleusen.

Der Meldende beschreibt auch, wann der Code in seinem Test lief: „When clicking ‚Open‘ in the ‚Attachments‘ tab, the code was executed in Chromium.“ Das ist seine Beobachtung, keine allgemeine Regel. In seinem Test lief der Code beim Klick auf „Open“ im Reiter „Attachments“, also beim Öffnen eines Anhangs, und zwar im Browser Chromium. Ob es weitere Wege gibt, sagt das Ticket nicht.

Die formale Prüfung schlug in diesem Test nicht an

Ein Detail aus dem Ticket verdient Aufmerksamkeit. Die präparierte Beispielrechnung wurde auch mit dem KoSIT-Validator geprüft, einem Prüfprogramm, das kontrolliert, ob eine XRechnung den Regeln des Standards entspricht. Das Ergebnis: „KoSIT Validator 1.6.3 with configuration v2026-08-31 classifies it as ACCEPTABLE.“ Die Rechnung mit dem eingeschleusten Code galt in diesem Test also als annehmbar.

Der Validator prüft die Regeln des Standards. Ob ein Programm die Inhalte einer Rechnung sicher anzeigt, ist eine andere Frage. Und genau die hat das Ticket aufgeworfen.

Wie sich die Lücke in einem bestimmten Programm auswirkt, hängt laut Ticket von der Einbindung ab: „The impact depends on how the HTML view is embedded, in particular on the CSP and origin isolation.“ CSP steht für Content Security Policy, eine Vorgabe, mit der eine Anwendung dem Browser mitteilt, welche Skripte er ausführen darf. Origin-Isolation bedeutet, dass eine Ansicht getrennt vom Rest der Anwendung läuft. Was ein eingeschleustes Skript im Einzelfall hätte bewirken können, beschreiben weder das Ticket noch die Meldung der KoSIT.

Vom Ticket zur korrigierten Fassung

Bis zum 12. Oktober 2026 war das Ticket vertraulich; ein Kommentar vom 10. Oktober 2026 spricht von „this issue is confidental“. Öffentlich wurde es an dem Tag, an dem die Korrektur ins Projekt übernommen und das Ticket geschlossen wurde. Die beiden Daten bezeichnen also zwei Schritte: Am 12. Oktober 2026 kam die Korrektur in den Programmcode des Projekts, am 13. Oktober 2026 erschien sie als neue Fassung, die Softwareanbieter in ihre Programme übernehmen können.

Die Fassung vom 13. Oktober 2026 trägt den Titel „XRechnung Visualization 2026-10-13 compatible with XRechnung 3.0“. Im Abschnitt „Fixed“ steht: „Bug that allowed injection of JavaScript code with BT-122 ‚Supporting document reference‘ and BT-125 ‚Attached document‘ filename“. Unter „Added“ ist eine Testdatei für genau diese Art von Code-Einschleusung hinzugekommen.

Das Ticket enthält noch einen Hinweis an die Entwickler: „The stylesheet is also used in other projects; please take these into account when addressing the issue.“ Welche Projekte gemeint sind, steht dort nicht.

Wer die Lage bewerten muss

Die KoSIT legt die Bewertung ausdrücklich in andere Hände. Ob und in welchem Umfang sich die Lücke in einem konkreten Einsatz auswirkt, müssen laut ihrer Meldung die Nutzenden beziehungsweise die verantwortlichen technischen Stellen beurteilen. Für einen kleinen Betrieb heißt das praktisch: Die Frage geht an den Anbieter des Programms, in dem Sie E-Rechnungen öffnen, oder an den Dienstleister, der Ihren Rechnungseingang eingerichtet hat.

Fragen lohnt sich überall dort, wo bei Ihnen eine XRechnung als lesbare Rechnung erscheint: im Buchhaltungs- oder Rechnungsprogramm, in einem ERP-System, in einem Portal, über das Sie Rechnungen mit Ihrer Steuerberatung austauschen, oder in einem eigens eingerichteten Rechnungseingang. Ob eine dieser Stellen die KoSIT-Visualisierung nutzt, wissen nur die jeweiligen Anbieter.

Was Sie Ihren Softwareanbieter fragen

Stellen Sie die Fragen am besten schriftlich, damit die Antwort später nachvollziehbar bleibt:

1. Nutzt die Anzeige von XRechnungen in Ihrem Programm die XRechnung-Visualisierung der KoSIT?
2. Falls ja: Ist die Fassung v2026-10-13 oder eine neuere eingespielt?
3. Falls ja, aber noch nicht aktualisiert: Wann kommt das Update, und müssen wir dafür selbst etwas tun?
4. Wie ist die HTML-Ansicht in Ihr Programm eingebunden, gerade mit Blick auf Content Security Policy und Origin-Isolation, die das KoSIT-Ticket als maßgeblich für die Auswirkung nennt?

Hat ein IT-Dienstleister oder eine Agentur für Sie einen eigenen Rechnungseingang gebaut, der XRechnungen im Browser anzeigt, stellen Sie dieselben Fragen dort. Nutzt Ihre Steuerberatung ein Portal, in dem Rechnungen angezeigt werden, gelten die Fragen sinngemäß für dessen Anbieter.

Bis eine Antwort vorliegt, ist eine alte Regel vernünftig: Anhänge in empfangenen E-Rechnungen nicht unbedacht öffnen, vor allem bei unbekannten Absendern. Einen verlässlichen Schutz verspricht das allerdings nicht. Der Klick auf einen Anhang ist nur der Weg, den der Meldende in seinem Test beobachtet hat. Die Korrektur selbst steckt in der Fassung v2026-10-13 des Bausteins, und die muss im Programm ankommen.

Was offen bleibt

Wir haben die Quellen am 16. Oktober 2026 gelesen. Folgende Punkte lassen sie offen:

• Welche Programme betroffen sind. Keine Quelle nennt Produkte.
• Welche älteren Fassungen die Lücke enthalten. Die KoSIT nennt keine betroffenen Versionen. Belegt ist nur, dass die Fassung v2026-10-13 die Korrektur enthält.
• Ob die Lücke ausgenutzt wurde. Dazu sagt keine Quelle etwas, weder in die eine noch in die andere Richtung.
• Wie schwer sie wiegt. Die KoSIT nennt keine CVE-Kennung, also keine Nummer im öffentlichen Verzeichnis für Sicherheitslücken, und keine Einstufung des Schweregrads.
• Was mit der PDF-Ausgabe ist. Ticket und Meldung betreffen die HTML-Darstellung. Zur PDF-Ausgabe äußern sie sich nicht.
• Ob die Anbieter die Korrektur ausliefern. Das lässt sich nur beim jeweiligen Anbieter erfragen.
• Was ein eingeschleustes Skript konkret bewirken kann. Belegt ist nur, dass Code ausgeführt werden konnte und dass die Wirkung von der Einbindung abhängt.

Wobei wir unterstützen

Betreuen wir Ihre Rechner im Rahmen unserer Managed Services, spielt das Patch Management Sicherheitspatches zeitnah ein. Ob ein Rechnungs- oder Buchhaltungsprogramm den korrigierten KoSIT-Baustein enthält, kann allerdings nur dessen Anbieter beantworten; eine Prüfung fremder Rechnungssoftware auf diesen Baustein übernehmen wir nicht. Wer Belege und Rechnungen nicht mehr abtippen möchte, findet unseren Ansatz bei der Prozessautomatisierung: Kommen die Belege immer von denselben Lieferanten und sehen gleich aus, lesen Power Automate oder n8n die Werte aus und übergeben sie an Ihre Buchhaltung. Sieht dagegen jeder Beleg anders aus, übernimmt KI das Auslesen.