CVE-Datenbank

Dell Container Storage Modules in Versionen vor 1.18.0 enthalten eine Schwachstelle durch unzureichende Neutralisierung spezieller Elemente, die in einer Template-Engine verwendet werden. Ein Angreifer mit geringen Berechtigungen und Fernzugriff könnte diese Schwachstelle potenziell ausnutzen, was zu einer Rechteausweitung führt.

Dell Container Storage Modules (CSM) Operator, Versionen vor 1.18.0, enthält eine Schwachstelle in der Privilegienverwaltung im ContainerStorageModule Custom Resource reconciler. Ein Angreifer mit geringen Berechtigungen und Fernzugriff könnte diese Schwachstelle potenziell ausnutzen, was zu einer Rechteausweitung und zum Erlangen von Root-Zugriff auf Clusterknoten führen könnte.

Dell Container Storage Modules, Versionen vor 1.18.0, enthalten eine Schwachstelle aufgrund fehlender Authentifizierung für eine kritische Funktion. Ein nicht authentifizierter Angreifer mit Fernzugriff könnte diese Schwachstelle potenziell ausnutzen, was zu einer Privilegienausweitung führt.

Dell Container Storage Modules, Versionen vor 1.18.0, enthalten eine Schwachstelle durch die Verwendung fest codierter Zugangsdaten in der CSM Authorization. Ein nicht authentifizierter Angreifer mit Fernzugriff könnte diese Schwachstelle potenziell ausnutzen, was zu einer Rechteausweitung führen könnte.

Dell Container Storage Modules, Versionen vor 1.18.0, enthalten eine Schwachstelle durch die Verwendung fest codierter Zugangsdaten in csm-docs. Ein nicht authentifizierter Angreifer mit Fernzugriff könnte diese Schwachstelle potenziell ausnutzen, was zur Offenlegung von Informationen führt.9.8

Dell Container Storage Modules (CSM), Versionen vor v1.18.0, weist im csm-authorization-storage-gRPC-Server eine Schwachstelle durch fehlende Authentifizierung für eine kritische Funktion auf. Ein nicht authentifizierter entfernter Angreifer könnte diese Schwachstelle potenziell ausnutzen und dadurch unbefugten Zugriff auf die Administratoranmeldedaten des Speicher-Backends für alle registrierten Speicher-Arrays erlangen.

vLLM ist eine Inferenz- und Serving-Engine für große Sprachmodelle. Vor Version 0.30.0 akzeptieren OpenAI-kompatible Anforderungsmodelle einen nicht leeren Wert für cache_salt, ohne die Zeichen- und Längenbeschränkungen durchzusetzen, die der Consumer IPCCacheServerKey in LMCache-MP erfordert. Bei Deployments, die den LMCache-MP-Connector verwenden, kann ein Salt, der ein unzulässiges Zeichen enthält oder die zulässige Länge überschreitet, während der Scheduler-Cache-Suche einen nicht abgefangenen ValueError auslösen, wodurch EngineCore beendet wird und allen gleichzeitigen Benutzern der Dienst verweigert wird. Dieses Problem wurde in Version 0.30.0 behoben.

Dies ist eine Schwachstelle in Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible und Fisheye. Diese Schwachstelle für beliebigen Dateizugriff ermöglicht es einem nicht authentifizierten Angreifer, in betroffenen Versionen auf bestimmte Dateien innerhalb des Stammverzeichnisses der Webanwendung zuzugreifen. Die Ausnutzung erfordert Vorkenntnisse über den exakten Namen und Pfad der Zieldatei; diese Schwachstelle ermöglicht es Angreifern nicht, Verzeichnisinhalte aufzuzählen oder aufzulisten. In einigen Konfigurationen können sensible Dateien vorhanden sein, die die Schwachstelle besonders schwerwiegend machen. Diese Schwachstelle ermöglicht es einem nicht authentifizierten Angreifer aus der Ferne, in betroffenen Versionen auf bestimmte Dateien innerhalb des Stammverzeichnisses der Webanwendung zuzugreifen. Die Schwachstelle muss für folgende betroffene Versionen behoben werden: -- Bitbucket Data Center, eingeführt ab Version >= 4.6.0, behobene Versionen: 9.4.26, 10.2.8, 10.5.1 -- Confluence Data Center, eingeführt ab Version >= 5.10.0, behobene Versionen 9.2.26, 10.2.19 -- Crowd Data Center, eingeführt ab Version >= 2.11.0, behobene Versionen 6.3.7, 7.0.3, 7.1.7, 7.2.4 -- Jira Software Data Center, eingeführt ab Version >= 7.1.0, behobene Versionen 9.12.40, 10.3.26, 11.3.12 -- Jira Service Management Data Center, eingeführt ab Version >= 3.1.0, behobene Versionen 5.12.40, 10.3.26, 11.3.12 -- Bamboo Data Center >= 7.0.1, behobene Versionen 10.2.24, 12.1.12 -- Crucible, behobene Version 4.9.15 -- Fisheye, behobene Version 4.9.15 -- Die Ausnutzung erfordert Vorkenntnisse über den exakten Namen und Pfad der Zieldatei. Die Schwachstelle umfasst nicht die Möglichkeit, Verzeichnisinhalte aufzuzählen oder aufzulisten.

Langflow ist ein Werkzeug zum Erstellen und Bereitstellen von KI-gestützten Agenten und Workflows. Vor Version 1.9.0 kann jeder authentifizierte Langflow-Benutzer durch Hinzufügen eines MCP-Servers mit dem Transport "Stdio" Remote Code Execution (RCE) auf dem Server erreichen. Das vom Benutzer angegebene Feld command wird ohne jede Validierung, ohne Allowlisting und ohne Sandboxing direkt an bash -c "exec {command}" übergeben. Der Befehl wird sofort ausgeführt, sobald die Serverliste abgerufen wird. Außerdem erlaubt das Feld env die beliebige Injektion von Umgebungsvariablen (z. B. LD_PRELOAD, Überschreiben von PATH). Diese Schwachstelle ist in Version 1.9.0 behoben.

Langflow ist ein Werkzeug zum Erstellen und Bereitstellen von KI-gestützten Agenten und Workflows. Vor Langflow 1.10.3 startete der MCP-stdio-Transport jeden Befehl und jedes Argument, die ein Benutzer in einer MCP-Server-Konfiguration angab, ohne Allowlist und (vor 1.10.3) eingebettet in `bash -c "exec {command} ..."`. Jeder Benutzer, der die MCP-Servereinstellungen ("Settings → MCP Servers → Add MCP Server", POST/PATCH /api/v2/mcp/servers/{server_name}) erreichen oder einen Flow mit der Komponente MCP Tools erstellen konnte, konnte einen "Server" hinzufügen, dessen Befehl ein beliebiger Betriebssystembefehl war (touch, rm -rf, eine Reverse Shell, ...). Der Befehl wurde auf dem Langflow-Host mit den Rechten des Langflow-Prozessbenutzers ausgeführt, sobald Langflow versuchte, sich mit dem Server zu verbinden (Auflisten der Server, Laden der Tools, Ausführen des Flows), auch dann, wenn die Benutzeroberfläche anschließend meldete, dass der stdio-Server nicht gestartet werden konnte. Bei der Standardeinstellung LANGFLOW_AUTO_LOGIN=true liefert GET /api/v1/auto_login ein Token ohne Anmeldedaten aus. Auf einer öffentlich erreichbaren Instanz mit der Standardkonfiguration war die Schwachstelle daher ohne Konto erreichbar. AUTO_LOGIN ist als nur für die Entwicklung vorgesehene Einstellung dokumentiert; bei deaktivierter Option konnte jeder authentifizierte Benutzer ohne Administratorrechte die Schwachstelle ausnutzen. Dieses Problem ist in Langflow 1.10.3, langflow-base 0.10.3 und lfx 1.10.3 behoben.

LibreOffice Calc kann einen Zellbereich mit einer externen Datenquelle verknüpfen, und die Verknüpfung wird im Dokument gespeichert. Ein Dokument könnte einen Java-Datenbanktreiber für eine solche Verknüpfung benennen, der von einem Remote-Standort geladen werden soll, sodass das Öffnen des Dokuments Java-Code von diesem Standort ausführen könnte. In behobenen Versionen muss ein Eintrag in einem Java-Klassenpfad eine file-URL sein.

Im NVD-Eintrag beschriebene Problem wurde in Ahsay AhsayCBS bis einschließlich 10.3.2 gefunden. Diese Schwachstelle betrifft nicht näher bekannten Code der Datei /rps/api/json/UpdateReceivers.do der Komponente Replication Receiver. Durch eine Manipulation des Arguments random kann es zu einer OS-Command-Injection kommen. Der Angriff kann aus der Ferne gestartet werden. Der Exploit wurde veröffentlicht und kann verwendet werden. Ein Upgrade auf Version 10.3.4 behebt das Problem. Ein Upgrade der betroffenen Komponente wird empfohlen.

Eine Schwachstelle wurde in Ahsay AhsayCBS bis einschließlich 10.3.2 entdeckt. Sie betrifft die Funktion checkSysPwd in der Datei com/ahsay/obs/api/ApiStructsAction.java der Komponente API. Durch eine Manipulation des Arguments random kommt es zu einer unzureichenden Authentifizierung. Der Angriff kann aus der Ferne gestartet werden. Der Exploit ist nun öffentlich verfügbar und kann verwendet werden. Ein Upgrade auf Version 10.3.4 kann dieses Problem beheben. Es wird empfohlen, die betroffene Komponente zu aktualisieren.

Schwachstelle in NetScaler ADC und NetScaler Gateway. Dieses Problem betrifft ADC: vor 14.1-73.41, vor 13.1-64.28, vor 14.1-73.41 FIPS und vor 13.1-37.282; Gateway: vor 14.1-73.41 und vor 13.1-64.28.

Der Webverwaltungsdienst in den betroffenen RouterOS-Versionen enthält einen Integer-Unterlauf bei der Verarbeitung des HTTP-Request-Bodys, der vor der Authentifizierung erreichbar ist. Dies kann von einem nicht authentifizierten Netzwerkangreifer mit einer einzigen präparierten Anfrage zur Ausführung beliebigen Codes als root oder zur Verursachung eines Denial-of-Service genutzt werden.

Das WebSocket-Backend verwendet Ladestationskennungen, um Sitzungen eindeutig zuzuordnen, erlaubt jedoch mehreren Endpunkten, sich mit derselben Sitzungskennung zu verbinden. Diese Implementierung führt zu vorhersehbaren Sitzungskennungen. Diese Schwachstelle kann es unbefugten Benutzern ermöglichen, sich als andere Benutzer zu authentifizieren, oder einem Angreifer ermöglichen, durch eine Überlastung des Backends mit gültigen Sitzungsanfragen einen Denial-of-Service-Zustand herbeizuführen.

Die WebSocket-Programmierschnittstelle unterliegt keinen Beschränkungen hinsichtlich der Anzahl von Authentifizierungsanfragen. Dieses Fehlen einer Ratenbegrenzung kann es einem Angreifer ermöglichen, Denial-of-Service-Angriffe oder Brute-Force-Angriffe durchzuführen, um sich unbefugten Zugriff zu verschaffen.

WebSocket-Endpunkten fehlen geeignete Authentifizierungsmechanismen, wodurch Angreifer Ladestationen imitieren können. Infolgedessen können Angreifer diese Schwachstelle ausnutzen, um unbefugten Zugriff auf sensible Daten zu erlangen oder unbefugte Aktionen auszuführen. Da keine Authentifizierung erforderlich ist, kann dies zu einer Rechteausweitung führen und möglicherweise die Sicherheit des gesamten Systems beeinträchtigen.

Die Sicherungs- und Wiederherstellungsroutine von Armatura One protokolliert den vollständigen Datenbankverbindungsbefehl einschließlich des Superuser-Passworts im Klartext in einer Protokolldatei auf dem Host. Die durch diesen Fund offengelegten Zugangsdaten können verwendet werden, um auf die Datenbank zuzugreifen, wenn Zugriff auf das Serverbetriebssystem besteht.

Die Datenbankinitialisierungsroutine von Armatura One weist dem Datenbank-Superuserkonto zum Zeitpunkt der Erstellung ein festes, vom Anbieter definiertes Passwort zu, anstatt pro Installation ein eindeutiges Passwort zu generieren. Eine Person mit Zugriff auf das Serverbetriebssystem und Kenntnis dieses Werts kann sich bei einer Bereitstellung, bei der das Passwort nicht geändert wurde, als Datenbank-Superuser authentifizieren.