OpsTree REMS: Reporter-Spoofing über Incident-API (unzureichende Autorisierung)
Zusammenfassung
OpsTree REMS bis einschliesslich 1.0.0 übernimmt beim Erstellen von Incidents oder beim Ändern des Incident-Status ein vom Client geliefertes Reporter-Feld. Ein authentifizierter Benutzer kann Incidents mittels manipulierter POST /api/v1/incidents- oder PATCH /api/v1/incidents/{id}/status-Anfragen einem anderen Benutzer zuordnen. Die Schwachstelle betrifft nur die Integrität: Die Zuordnung von Incidents und der Accountability-Audit-Trail können verfälscht werden, es werden jedoch keine Daten direkt offengelegt und keine Übernahme beschrieben. Für den Angriff ist ein gültiges REMS-Konto erforderlich.
Betroffen
- OpsTree Solutions REMS, Versionen 0 bis einschliesslich 1.0.0
- Betroffene Endpunkte: POST /api/v1/incidents und PATCH /api/v1/incidents/{id}/status
- Korrigierte Version: Unbekannt.
Behoben in
Unbekannt. Der Hersteller soll das Problem bestätigt und die Behebung bestätigt haben, in den geprüften Quellen ist jedoch keine korrigierte Versionsnummer veröffentlicht.
Umgehung
- Keine vom Hersteller bestätigte Massnahme.
- Zugriff auf die APIs zum Erstellen und Ändern des Status von Incidents auf vertrauenswürdige Benutzer beschränken.
- REMS-Konten auf Personen beschränken, die sie benötigen, und die Verwaltungsoberfläche vom öffentlichen Internet fernhalten.
- Reporter-Felder von Incidents mit den Login-Protokollen abgleichen.
Ausnutzung
- Keine bekannte Ausnutzung in freier Wildbahn; kein Eintrag im CISA KEV.
- Ein öffentlicher Proof of Concept ist nicht verifiziert: Eine Referenz ist als technische Beschreibung eines Exploits gekennzeichnet, während VulDB angibt, dass kein Exploit verfügbar ist.
Unsere Empfehlung
- Prüfen, ob REMS installiert ist und welche Versionen eingesetzt werden.
- Auf eine korrigierte Version aktualisieren, sobald OpsTree eine veröffentlicht; Herstellerseite und NVD regelmässig prüfen.
- Bis zur Korrektur REMS-Konten und API-Zugriff einschränken und die Oberfläche vom Internet fernhalten.
- Incident-Einträge auf Reporter-Werte überwachen, die nicht mit den Login-Protokollen übereinstimmen.
- Auch CVE-2026-126768 (Bewertung 9.8) prüfen, falls REMS eingesetzt wird.
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- CVE Record CVE-2026-126766 www.cve.org
- VulnCheck advisory www.vulncheck.com
- GitHub gist (REMS-CVE-10) gist.github.com
- VulDB CVE entry vuldb.com
- Offseq threat entry radar.offseq.com
- OpsTree REMS product page opstree.com
Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 11.11.2026 20:47.
Quellen
Der Tracker verbindet offizielle, frei nutzbare Datenquellen – laufend aktualisiert:
- NVD (NIST) – CVE, Bewertung (CVSS), betroffene Produkte
- CISA KEV – von der CISA bestätigt aktiv ausgenutzte Lücken
- CISA Vulnrichment – Einschätzung der CISA (SSVC) im offiziellen CVE-Eintrag
- FIRST EPSS – Wahrscheinlichkeit einer Ausnutzung
- Microsoft MSRC – Patch Tuesday: Lücken, Schweregrad, Updates
- PoC-in-GitHub – öffentliche Proof-of-Concept-Repositories
- Metasploit (Rapid7) – Module des Metasploit Framework
- Exploit-DB (OffSec) – Archiv öffentlicher Exploits (nur Verweise)
- Patch-Tage: offizielle Seiten der Hersteller (je Hersteller verlinkt) (Patch-Tage der Hersteller)
Dieses Angebot nutzt Daten der NVD-API, ist aber von der NVD weder unterstützt noch zertifiziert. EPSS-Daten © FIRST.org.
Betroffen? Wir helfen.
Wir prüfen, ob Ihre Systeme betroffen sind, spielen Updates ein und schliessen die Lücke – auf Wunsch auch laufend mit dem System Health Checker.
