Am 5. August 2026 stellten Forscher von Novee unter der Leitung von Lidor Ben Shitrit auf der Black Hat USA eine Arbeit vor, die zwölf Schwachstellen in vier Java-Unternehmensplattformen offenlegte, darunter zwei kritische Ketten, die Codeausführung auf dem Server ganz ohne Anmeldung ermöglichen: in der Workflow-Plattform Bonita BPM und in Apache OFBiz, dem Open-Source-ERP. Die praktische Erkenntnis für jeden Unternehmer: Das System, das Sie für geschützt halten, weil es intern ist, lässt sich mit zwei Browser-Anfragen erreichen, wenn es erreichbar und ungepatcht ist. Echter Schutz beginnt mit einer Bestandsaufnahme dessen, was Sie betreiben, und einer festen Patch-Routine, nicht mit Vertrauen in den Netzwerkperimeter.

Was die Forscher tatsächlich gefunden haben

Die Forschung beruhte nicht auf einem einzigen spektakulären Fehler. Sie entstand durch die Kombination kleiner, verbreiteter Middleware-Fehler: Unterschiede bei der Auswertung einer URL, unvollständiger Schutz in der Schicht, die Anfragen verarbeitet, fest im Quellcode hinterlegte kryptografische Schlüssel und unsichere Template-Auswertung. Einzeln wirkt keiner davon gefährlich, und genau deshalb überstehen sie Code-Reviews und werden als niedrige Priorität abgelegt. Miteinander verkettet ergeben sie einen vollständigen Weg vom anonymen Besucher bis zur Befehlsausführung auf dem Server. Von den zwölf Schwachstellen funktionieren vier vor der Authentifizierung, und eine durchbricht die Isolation innerhalb der Ausführungs-Sandbox.

Die BadBonita-Kette: drei Schwachstellen ergeben eine vollständige Kompromittierung

Die erste Kette betrifft Bonita BPM in Version 10.4.3. Sie beginnt mit einer Umgehung der Authentifizierung, die aus drei verknüpften Schwächen besteht: Path Traversal mit der Notation ..;, ein Sicherheitsfilter, der auf einen Teilstring statt auf den vollständigen Pfad prüft, und interne Logik zur Weiterleitung von Anfragen. Das Ergebnis: Eine Anfrage erreicht eine interne API, die niemand von außen jemals sehen sollte. Diese API akzeptiert nicht vertrauenswürdiges XML und übergibt es direkt an die Bibliothek XStream, die es deserialisiert, und über eine bekannte Gadget-Kette aus Commons Collections endet der Weg mit Groovy-Befehlen, die auf dem Server ausgeführt werden.

Beachten Sie, dass keiner dieser Schritte ein geleaktes Passwort, Social Engineering oder vorherigen Zugang erfordert. Der Angreifer braucht lediglich, dass das System über das Netzwerk erreichbar ist.

OFBiz: ein Signaturschlüssel in einem öffentlichen Repository

Das zweite Problem, geführt als CVE-2026-31986 und als kritisch eingestuft, betrifft Apache OFBiz in Version 24.09.05, wenn Single Sign-on aktiviert ist. Das Problem: Die Standard-Signaturschlüssel stehen im öffentlich zugänglichen Quellcode, und weil viele Installationen die Voreinstellungen nicht anfassen, kann ein Angreifer ein gültiges SSO-Token im Namen eines Administratorkontos fälschen. Von dort passiert die Anfrage eine Sperrliste, die Wörter wie java, process und import blockieren sollte. Die Liste unterschied jedoch zwischen Groß- und Kleinschreibung und prüfte bestimmte Muster, sodass es genügt, einen Buchstaben großzuschreiben oder einen anderen automatisch importierten Klassennamen zu verwenden, um durchzuschlüpfen. Das Endergebnis: Zwei nicht authentifizierte GET-Anfragen reichen aus, um auf jeder Installation mit SSO zur Codeausführung zu gelangen.

Warum das gerade Sie betrifft

Weil keines der beiden ein Randwerkzeug ist. OFBiz ist ein Open-Source-ERP, mit dem viele Unternehmen Lagerbestand, Einkauf und Rechnungsstellung steuern, und Bonita ist eine Workflow-Engine, die interne Freigaben und Abläufe antreibt. Wer an diese beiden Stellen gelangt, liest nicht nur Daten, sondern steht mitten in Ihrem operativen Kreislauf: Bestellungen, Lieferantenpreise, Personalakten, Kundenhistorie. Die Forscher berichteten, dass beide Anbieter innerhalb der üblichen Offenlegungsfrist von neunzig Tagen korrigierte Versionen veröffentlicht haben. Das Update existiert also, und die Verantwortung liegt jetzt bei dem, der das System betreibt, nicht bei dem, der es gebaut hat.

Die eigentliche Lücke am Markt sind nicht fehlende Patches, sondern eine fehlende Bestandsaufnahme. Viele Organisationen haben keine aktuelle Liste dessen, was sie tatsächlich betreiben, in welcher Version und unter welcher Domain. So hängt eine alte Staging-Kopie zwei Jahre lang auf einer vergessenen Subdomain und wird zur Tür, an die niemand gedacht hat.

Was Sie diese Woche tun sollten

  • Erfassen Sie Ihre Systeme: eine schriftliche Liste aller Systeme, die Sie betreiben, mit Version, Angabe, ob sie aus dem Internet erreichbar sind, und namentlich benanntem Verantwortlichen.
  • Aktualisieren Sie Bonita und OFBiz sofort auf die korrigierten Versionen, falls Sie eines davon einsetzen, und lesen Sie vor dem Upgrade die offizielle Sicherheitsseite von Apache.
  • Ersetzen Sie jeden Standardschlüssel für Verschlüsselung oder Signatur, der mit dem Produkt ausgeliefert wurde. Kein Wert, der in der Dokumentation abgedruckt ist, ist ein Geheimnis.
  • Schließen Sie Admin-Zugänge zum offenen Internet und erreichen Sie sie über ein privates Netzwerk oder eine kurze Liste zugelassener Adressen.
  • Legen Sie alte Staging-Kopien und ungenutzte Subdomains still. Sie sind das leichteste und am wenigsten überwachte Ziel.
  • Aktivieren Sie die Zugriffsprotokollierung und bewahren Sie die Protokolle auf. Ohne Protokolle können Sie später nicht beantworten, ob überhaupt jemand eingedrungen ist.

Die technische Lehre: Das interne Netzwerk ist keine Sicherheitsgrenze

Die wichtigste Empfehlung aus dieser Forschung lautet, internes Routing mit Kontrollen auf Internet-Niveau zu behandeln. Die alte Vorstellung, dass alles hinter der Firewall sicher sei, ist in der Praxis gescheitert: Eine einzige Schwachstelle zur Umgehung der Authentifizierung verwandelt jeden internen Endpunkt in einen öffentlichen. Daraus folgen drei technische Regeln, die in Ihre Entwicklungsstandards gehören:

Verlassen Sie sich niemals auf eine Sperrliste, um eine gefährliche Operation zu schützen. Wenn die Auswertung von Ausdrücken in einem Codepfad nicht nötig ist, entfernen Sie sie vollständig, statt zu versuchen, sie zu filtern.

Die zweite Regel lautet, eine sensible Operation niemals von einem Konfigurations-Flag oder einer Benutzereinstellung abhängig zu machen, die sich innerhalb des Systems ändern lässt. Die dritte besteht darin, die Logik von Authentifizierungsfiltern auf jeden Teilstring-Abgleich zu prüfen, denn das ist der häufigste und am leichtesten ausnutzbare Fehler dieser Klasse. Wenn wir bei Origami neue Geschäftssysteme entwickeln, wenden wir das standardmäßig an: explizite Autorisierung an jedem Endpunkt und kein Vertrauen, das sich aus der Position einer Anfrage im Netzwerk ableitet.

Der regulatorische Aspekt in Saudi-Arabien

Wenn das kompromittierte System personenbezogene Daten von Personen im Königreich enthält, ist das keine rein technische Angelegenheit mehr. Das Gesetz zum Schutz personenbezogener Daten (PDPL) verpflichtet den Verantwortlichen, die notwendigen Maßnahmen zum Schutz dieser Daten zu treffen und Vorfälle zu melden, die deren Vertraulichkeit beeinträchtigen. Die Nationale Cybersicherheitsbehörde (NCA) veröffentlicht grundlegende Kontrollen zu Schwachstellenmanagement, Patching und Asset-Management, also genau die Kontrollen, die diese Kette gestoppt hätten. Eine alte Version eines Produkts mit einer bekannten, bereits behobenen Schwachstelle zu betreiben, ist in jedem Audit eine schwer zu verteidigende Position.

Die einfache Regel: Behandeln Sie Sicherheitsupdates als monatliche betriebliche Verpflichtung mit einem Verantwortlichen und einem Termin, nicht als Notfallaufgabe nach einem Vorfall.

Quellen

  • Help Net Security — Details zu den RCE-Ketten ohne Authentifizierung und zu CVE-2026-31986: helpnetsecurity.com
  • Offizielle Sicherheitsseite von Apache OFBiz: ofbiz.apache.org/security.html
  • Nationale Cybersicherheitsbehörde (NCA) — Kontrollen und regulatorische Rahmenwerke: nca.gov.sa
  • Saudische Behörde für Daten und künstliche Intelligenz (SDAIA) — Gesetz zum Schutz personenbezogener Daten: sdaia.gov.sa