CVE-Datenbank

Bridge ist von einer Schwachstelle durch nicht vertrauenswürdigen Suchpfad betroffen, die zu einer Ausführung von beliebigem Code im Kontext des aktuellen Benutzers führen könnte. Ein Angreifer mit niedrigen Privilegien könnte diese Schwachstelle ausnutzen, um beliebigen Code auszuführen. Die Ausnutzung dieses Problems erfordert eine Benutzerinteraktion, indem ein Opfer eine bösartige Datei öffnen muss. Der Geltungsbereich ist geändert.

Bridge ist von einer Incorrect Authorization-Schwachstelle betroffen, die zu einer Privilegieneskalation führen könnte. Ein Angreifer könnte diese Schwachstelle ausnutzen, um unbefugten Lese- und Schreibzugriff zu erlangen. Die Ausnutzung dieses Problems erfordert eine Benutzerinteraktion, bei der ein Opfer eine bösartige Datei öffnen muss. Scope ist geändert.

Bridge ist von einer Schwachstelle durch unsachgemäße Begrenzung eines Pfadnamens auf ein eingeschränktes Verzeichnis ('Path Traversal') betroffen, die zu beliebigem Lesen des Dateisystems führen könnte. Ein Angreifer könnte diese Schwachstelle ausnutzen, um auf sensible Dateien und Verzeichnisse außerhalb des vorgesehenen Zugriffsbereichs zuzugreifen. Die Ausnutzung dieses Problems erfordert eine Benutzerinteraktion, indem ein Opfer eine bösartige Datei öffnen muss.

Ein Lesen außerhalb der Grenzen wurde durch eine verbesserte Grenzprüfung behoben. Dieses Problem wurde in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6 behoben. Eine App kann möglicherweise auf sensible Benutzerdaten zugreifen.

Build-Leser können auf die Umgebungseigenschaften eines anderen Repositorys zugreifen. Ein Aufrufer mit Lesezugriff auf ein gewöhnliches Repository kann beim Abrufen von Umgebungseigenschaften für einen geschützten Build einen lesbaren Repository-Parameter auswählen und so Geheimnisse der Build-Umgebung offenlegen (Auswirkung auf die Vertraulichkeit; keine Auswirkung auf Integrität oder Verfügbarkeit nachgewiesen).

Eine authentifizierte Privilege-Escalation-Schwachstelle in JFrog Platform kann unter von einem Administrator bereitgestellten Kontobedingungen ausgenutzt werden. Eine erfolgreiche Ausnutzung kann temporären Plattform-Administrator-Zugriff gewähren.

JFrog Artifactory enthält eine Schwachstelle in der Authentifizierungsbehandlung bei der internen Anfrageverarbeitung, die es einem Angreifer unter bestimmten Bedingungen ermöglichen kann, Privilegien über das vorgesehene Zugriffsniveau hinaus zu eskalieren.

Ein Benutzer mit Lesezugriff auf ein JFrog Artifactory Cargo-Remote-Repository könnte Artifactory dazu bringen, unbeabsichtigte URLs anzufordern und die Antwort zurückzugeben.

Die Unterstützung von JFrog Artifactory für Terraform-Remote-Repositories wurde als anfällig für Server-Side Request Forgery (SSRF) befunden. Ein authentifizierter Benutzer – oder, wenn anonymer Zugriff auf das Repository aktiviert ist, ein nicht authentifizierter Benutzer – könnte Artifactory dazu veranlassen, ausgehende HTTP-Anfragen an beliebige Ziele zu senden und den Antwortinhalt zu erhalten.

Eine Schwäche bei der URL-Validierung in der Ansible-Repository-Verarbeitung von JFrog Artifactory könnte es einem Benutzer unter bestimmten Repository-Zugriffsbedingungen ermöglichen, unbeabsichtigte serverseitige Anfragen zu verursachen. Das Problem beeinträchtigt hauptsächlich Vertraulichkeit und Integrität und wurde in korrigierten Artifactory-Versionen behoben.

Eine Schwachstelle bei der Pfadvalidierung in der Archiv-Extraktions-/Schreibverarbeitung ermöglicht es, Einträge mit Traversal-Sequenzen außerhalb des vorgesehenen Speicherorts für Build-Artefakte zu schreiben.

Eine Deserialisierungsschwachstelle in der Paketverarbeitung von JFrog Artifactory könnte es einem Benutzer mit geringen Privilegien ermöglichen, unter bestimmten Repository-Bedingungen Vertraulichkeit, Integrität und Verfügbarkeit zu beeinträchtigen.

JFrog Artifactory (Self Hosted) Versionen vor 7.133.11 sind anfällig für einen Privilege-Escalation-Angriff aufgrund einer Validierungsprüfung der Token-Signatur/des Token-Issuers und nicht des Token-Scopes.

In JetBrains TeamCity vor 2026.1.3, 2025.11.7 war unauthentifizierte Remote Code Execution über das Agent-Polling-Protokoll möglich

VeloCloud Orchestrator (VCO) on-prem weist ein Sicherheitsproblem auf, bei dem ein Remote-Angreifer möglicherweise auf privilegierte interne Funktionen zugreifen und den VCO-Host beeinträchtigen kann. Eine erfolgreiche Ausnutzung kann die Vertraulichkeit, Integrität und Verfügbarkeit des Orchestrators und der vom Orchestrator verwalteten Daten kompromittieren. Diese Funktionalität war nur für den internen Gebrauch bestimmt und ist nicht für den Remote-Zugriff vorgesehen. Die gehosteten und dedizierten Versionen von VCO wurden bereits vor der Veröffentlichung dieser Mitteilung gepatcht. Dieses Problem wurde extern entdeckt und wird bekanntermaßen aktiv ausgenutzt.

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: net: openvswitch: übergroße verschachtelte Aktionsattribute ablehnen Open vSwitch speichert generierte Flow-Aktionen als nlattrs, deren nla_len-Feld u16 ist. Der Commit a1e64addf3ff („net: openvswitch: remove misbehaving actions length check“) erlaubte es, dass der gesamte sw_flow_actions-Datenstrom über 64 KiB hinauswächst, was gültig ist, entfernte jedoch auch die letzte Schutzvorrichtung, die verhinderte, dass ein generiertes verschachteltes Aktionsattribut U16_MAX überschreitet. Ein generierter Container mit Übergröße kann somit mit einem abgeschnittenen nla_len abgeschlossen werden. Ein späterer Dump oder Teardown durchläuft dann einen strukturell anderen Datenstrom als den, der validiert wurde. Insbesondere kann eine übergroße verschachtelte CLONE/CT-Aktion dazu führen, dass nachfolgende Bytes im generierten Datenstrom als unabhängige Aktionen interpretiert werden. Das größere Verhalten des gesamten Aktionsdatenstroms wird beibehalten, aber das Schließen verschachtelter Aktionen wird so geändert, dass generierte Container abgelehnt werden, die nicht in nla_len passen, und der Fehler wird über alle Aufrufer zurückgegeben. Für rekursive Builder von SAMPLE, CLONE, DEC_TTL und CHECK_PKT_LEN werden ressourcenbesitzende Enden von Aktionslisten in umgekehrter Erstellungsreihenfolge gekürzt, bevor fehlgeschlagene Wrapper verworfen werden, damit in die verworfenen Enden kopierte Ressourcen freigegeben werden, bevor die Wrapper entfernt werden. Die meisten fehlgeschlagenen äußeren Wrapper werden verworfen, indem actions_len gekürzt wird, nachdem die Ressourcen der untergeordneten Elemente freigegeben wurden. CHECK_PKT_LEN kürzt außerdem sein übergeordnetes Element, nachdem die Ressourcen der Zweige entfernt wurden. Fehler beim Schließen von SET/TUNNEL lösen den bekannten Besitz von tun_dst direkt auf, und SET_TO_MASKED hat keinen externen Besitz und kürzt bei einem Fehler beim Schließen.

Im Linux-Kernel wurde folgende Schwachstelle behoben: bpf: Unterstützung für die Härtung gegen JIT-Spraying Der BPF-JIT-Allokator packt viele kleine Programme in größere ausführbare Allokationen und verwendet den Speicher innerhalb dieser Allokationen wieder, wenn Programme geladen und freigegeben werden. Wenn neuer Code in einen Speicherbereich geschrieben wird, den zuvor ein Programm belegt hat, kann ein indirekter Sprung in das neue Programm eine Branch-Vorhersage wiederverwenden, die vom alten Programm zurückgelassen wurde. Die indirekten Branch-Prädiktoren werden geleert, bevor JIT-Speicher wiederverwendet wird, damit indirekte Sprünge in ein neu geschriebenes Programm keine Vorhersagen eines alten Programms wiederverwenden, das denselben Speicherbereich belegt hat. Der statische Schlüssel bpf_arch_pred_flush_enabled und der statische Aufruf bpf_arch_pred_flush werden eingeführt, um die Branch-Prädiktoren bei der Wiederverwendung von JIT-Speicher zu leeren. Architekturen, die ein Leeren benötigen, können ihn auf eine Funktion zum Leeren des Prädiktors aktualisieren. Standardmäßig ist er ein NOP und gibt keinen CALL aus. Allokationen, die größer als ein Pack sind, werden von diesem Leeren nicht abgedeckt. Das ist sicher, weil cBPF-Programme (die Angriffsfläche für nicht privilegierte Benutzer) deutlich kleiner als eine Pack-Größe begrenzt sind. Eine Warnung wird ausgegeben, falls diese Annahme jemals verletzt wird, während das Leeren aktiv ist.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: x86/bugs: IBPB-Flush bei BPF-JIT-Allokation aktivieren Härtung gegen JIT-Spraying aktivieren, wenn Spectre-v2-Mitigationen verwendet werden. Konkret bei der Wiederverwendung von BPF-JIT-Speicher einen IBPB-Flush auslösen. Den IBPB-Flush nicht aktivieren, wenn der BPF-Dispatcher bereits eine Retpoline-Sequenz verwendet. Diese Härtung gilt nur, wenn BPF-JIT verwendet wird. Die Aktivierung unter CONFIG_BPF_JIT schützen, damit bugs.c weiterhin mit CONFIG_BPF_JIT=n gebaut wird.

Das Tycon Systems TPDIN-Monitor-WEB2 wird ohne konfigurierte HTTP-Zugangsdaten ausgeliefert; vorgesehen ist, dass ein Installateur sie bei der ersten Verwendung festlegt. Bei Firmware 2.4.4 und früher stellt ein Gerät, das in diesem unkonfigurierten Zustand belassen wird, die Web-Verwaltungsoberfläche bereit, ohne dass eine Anmeldung erforderlich ist. Ein Angreifer mit Netzwerkzugriff auf ein solches Gerät kann auf die vollständigen Gerätesteuerungen zugreifen, einschließlich der Verwaltung der Leistungsrelais, des Geräteneustarts, der Konfiguration des Fernzugriffsdienstes und der Netzwerkeinstellungen, was zu einer Störung der angeschlossenen Infrastruktur oder zu physischen Schäden an Geräten führen könnte.

Das Web-Management-Interface in Tycon Systems TPDIN-Monitor-WEB2 speichert und zeigt Systemanmeldedaten im Klartext auf einer bestimmten Konfigurationsseite an, die für authentifizierte Benutzer zugänglich ist. Jeder mit Zugriff auf das administrative Dashboard kann diese Anmeldedaten sofort auslesen, die zur Kompromittierung anderer Systeme im lokalen Netzwerk verwendet werden können.