CVE-Datenbank

Schwache Authentifizierung in Microsoft Office SharePoint ermöglicht es einem nicht autorisierten Angreifer, über ein Netzwerk eine Sicherheitsfunktion zu umgehen.

Falsche Autorisierung in Active Directory Certificate Services (AD CS) ermöglicht es einem autorisierten Angreifer, Berechtigungen über ein Netzwerk zu erweitern.

Fehler im Schutzmechanismus in Windows BitLocker ermöglicht es einem nicht autorisierten Angreifer, eine Sicherheitsfunktion mit einem physischen Angriff zu umgehen.

Die Deserialisierung nicht vertrauenswürdiger Daten in Microsoft Office SharePoint ermöglicht es einem nicht autorisierten Angreifer, Code über ein Netzwerk auszuführen.

Fehlende Authentifizierung für kritische Funktion in Microsoft Office SharePoint ermöglicht es einem unbefugten Angreifer, über ein Netzwerk Berechtigungen zu eskalieren.

Deserialisierung nicht vertrauenswürdiger Daten in Microsoft Office SharePoint ermöglicht es einem nicht autorisierten Angreifer, Code über ein Netzwerk auszuführen.

Unsachgemäße Neutralisierung von in einem Befehl verwendeten Sonderelementen ('command injection') in Copilot Chat (Microsoft Edge) ermöglicht es einem nicht autorisierten Angreifer, Code über ein Netzwerk auszuführen.

Schutzmechanismusfehler im Windows Event Logging Service ermöglicht einem autorisierten Angreifer die Offenlegung von Informationen über ein Netzwerk.

SAP Commerce Cloud könnte einen Beispiel-OAuth2-Client mit öffentlich dokumentierten Beispielanmeldedaten beibehalten, die aus einer Beispielkonfiguration aus der SAP Help Portal-Dokumentation stammen. Wenn unverändert belassen, könnte ein nicht authentifizierter Angreifer diese bekannten Anmeldedaten verwenden, um ein gültiges Zugriffstoken zu erhalten und bestimmte APIs zum Lesen und Ändern von Daten aufzurufen. Eine erfolgreiche Ausnutzung führt zu hohen Auswirkungen auf Vertraulichkeit und Integrität, ohne Auswirkungen auf die Verfügbarkeit.

ServiceNow hat eine Remote-Code-Execution-Schwachstelle behoben, die in der ServiceNow AI Platform identifiziert wurde. Diese Schwachstelle könnte es einem nicht authentifizierten Benutzer unter bestimmten Umständen ermöglichen, Code innerhalb der ServiceNow Platform auszuführen. ServiceNow hat diese Schwachstelle durch die Bereitstellung eines Sicherheitsupdates für gehostete Instanzen behoben. Relevante Sicherheitsupdates wurden auch für ServiceNow Self-Hosted-Kunden und -Partner bereitgestellt. Darüber hinaus ist die Schwachstelle in den aufgeführten Patches und Family Releases behoben, die gehosteten und selbst gehosteten Kunden sowie Partnern zur Verfügung gestellt wurden. Uns ist derzeit keine Ausnutzung gegen ServiceNow-Instanzen bekannt. Wir empfehlen Kunden, umgehend entsprechende Updates anzuwenden oder auf eine gepatchte Version zu aktualisieren, falls sie dies noch nicht getan haben.

Rejetto HFS 3.0.0 bis 3.2.0 leitet seinen Signaturschlüssel für Sitzungscookies vom nicht kryptografischen Generator Math.random() ab und gibt nicht authentifizierten Clients während der Anmeldung Ausgaben desselben Generators preis. Ein entfernter Angreifer kann eine kleine Anzahl von Anmeldeantworten sammeln, den Zustand des Generators rekonstruieren, den Signaturschlüssel wiederherstellen und ein gültiges Sitzungscookie für einen Administrator fälschen, was zu vollständigem administrativem Zugriff und zur Ausführung von Code aus der Ferne über die Konfigurationsfunktion server_code führt.

Flowise vor 3.1.0 (betroffene Versionen 3.0.13 und früher) verwendet schwache fest kodierte Standard-JWT-Geheimnisse ('auth_token', 'refresh_token') sowie Standardwerte für Audience und Issuer ('AUDIENCE', 'ISSUER') in der Enterprise-Passport-Authentifizierungs-Middleware (packages/server/src/enterprise/middleware/passport/index.ts). Wenn die entsprechenden Umgebungsvariablen (JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, JWT_AUDIENCE, JWT_ISSUER) nicht gesetzt sind, greift die Anwendung stillschweigend auf diese öffentlich bekannten Standardwerte zurück, wodurch ein Angreifer gültige JWTs fälschen und sich als beliebiger Benutzer, einschließlich Administratoren, ausgeben kann, was zu einer Umgehung der Authentifizierung führt.

Der iDirect iQ200 stellt die REST-API-Endpunkte /api/identity und /api/ ohne Authentifizierung bereit. Ein nicht authentifizierter Angreifer mit Netzwerkzugriff kann vertrauliche Geräteinformationen abrufen, darunter die Seriennummer, die Geräte-ID (DID), den Bezeichner des privaten Terminalschlüssels (TPK), die MAC-Adresse und die genaue Firmware-Version. Die DID und der TPK werden zur Authentifizierung im Satellitennetzwerk der iDirect-Plattform verwendet und können dadurch möglicherweise die Identitätsvortäuschung eines Terminals und die Erkundung des Netzwerks ermöglichen.

Der iDirect iQ200 validiert nach der Authentifizierung keine CSRF-Tokens bei API-Endpunkten, die den Zustand ändern. Der Endpunkt /api/reboot akzeptiert POST-Anfragen, die ausschließlich durch ein Session-Cookie authentifiziert werden, dem das SameSite-Attribut fehlt. Ein entfernter Angreifer kann eine bösartige Webseite hosten, die beim Besuch durch einen authentifizierten Administrator automatisch eine Cross-Site-POST-Anfrage sendet und dadurch einen sofortigen Neustart des Geräts sowie den Verlust der Satellitenverbindung verursacht. Wiederholte Angriffe können einen Denial-of-Service-Zustand aufrechterhalten.

Das Plugin Super Forms – Drag & Drop Form Builder für WordPress ist in allen Versionen bis einschließlich 6.3.313 anfällig für Arbitrary File Upload über die Funktion submit_form. Dies ist auf eine fehlende Dateitypvalidierung und das Fehlen jeglicher Capability-Prüfung im submit_form-nopriv-AJAX-Handler zurückzuführen, dessen einzige Hürde ein Session-Nonce ist, das von nicht authentifizierten Besuchern über einen separaten nopriv-Endpunkt frei erhältlich ist. Dies ermöglicht es nicht authentifizierten Angreifern, Dateien hochzuladen, die ausführbar sein können, was Remote Code Execution ermöglicht. Die Nonce-Anforderung wird trivial umgangen, da die super_create_nonce-nopriv-AJAX-Action jedem nicht authentifizierten Besucher erlaubt, mit einer einzigen vorherigen Anfrage einen gültigen sf_nonce und ein Session-Cookie zu erstellen, wodurch die Ausnutzung auf zwei nicht authentifizierte HTTP-Requests reduziert wird.

Ruflo ist ein Agent-Meta-Harness für Claude Code und Codex. Vor 3.16.3 legte die standardmäßige docker-compose-Bereitstellung von ruflo die MCP bridge-Endpunkte POST /mcp und POST /mcp/:group ohne Authentifizierung offen, wodurch ein unauthentifizierter Netzwerk-Angreifer tools/call an terminal_execute aufrufen, eine Shell im bridge-Container erlangen, Provider-API-Keys lesen und AgentDB learning-store-Patterns vergiften konnte. Dieses Problem ist in Version 3.16.3 behoben.

LiteLLM ist ein Proxy-Server (AI Gateway) zum Aufrufen von LLM-APIs im OpenAI-Format (oder nativen Format). Vor 1.84.0 erlaubte der MCP Streamable HTTP endpoint von LiteLLM einem nicht authentifizierten Angreifer, einen gefälschten Authorization-Header zu verwenden, um einen OAuth2-Passthrough-Fallback-Pfad auszulösen, der die fehlgeschlagene LiteLLM-Schlüsselvalidierung durch ein leeres UserAPIKeyAuth()-Objekt ersetzte, sodass Anfragen ohne gültigen LiteLLM-Schlüssel das MCP-Tooling erreichen konnten. Dieses Problem ist in Version 1.84.0 behoben.

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: ipv6: fraggap im Pfad der seitenweisen Allokation berücksichtigen In __ip6_append_data() werden bei Auswahl des Zweigs für die seitenweise Allokation (MSG_MORE / NETIF_F_SG / large fraglen) alloclen und pagedlen wie folgt berechnet: alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen enthält bereits fraggap (datalen = length + fraggap). Wenn fraggap nicht null ist, handelt es sich nicht um das erste skb und transhdrlen ist null. Die aus dem vorherigen skb übernommenen fraggap-Bytes werden direkt hinter den Fragment-Headern im linearen Bereich des neuen skb kopiert. Der lineare Bereich ist daher um fraggap Bytes zu klein, während pagedlen um denselben Betrag zu groß angesetzt ist, und der Kopiervorgang schreibt über skb->end hinaus in die nachfolgende skb_shared_info. Ein nicht privilegierter Benutzer kann dies über einen UDPv6-Socket unter Verwendung von MSG_MORE zusammen mit MSG_SPLICE_PAGES auslösen. Die fehlerhafte Berechnung wurde durch Commit 773ba4fe9104 ("ipv6: avoid partial copy for zc") eingeführt. Vor Commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES") führte der negative Kopierwert zur Rückgabe von -EINVAL. Dieses spätere Commit ermöglichte es MSG_SPLICE_PAGES, in diesem Fall fortzufahren, wodurch die Beschädigung auslösbar wurde. Der Zweig ohne Seiten setzt alloclen auf fraglen, das fraggap bereits berücksichtigt, da dies auch für datalen gilt. Den Zweig mit Seiten anpassen, indem fraggap zu alloclen addiert und von pagedlen subtrahiert wird. Nach dieser Anpassung fällt copy im Pfad mit Seiten nicht mehr auf -fraggap zusammen, daher den veralteten Kommentar entfernen, der diese alte Arithmetik beschreibt. Da ein negativer copy für einen gültigen MSG_SPLICE_PAGES-Fall nicht mehr erwartet wird, die MSG_SPLICE_PAGES-Ausnahme aus der Prüfung auf einen negativen copy entfernen.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: KVM: x86: Behebung eines Use-after-free beim Shadow Paging aufgrund einer unerwarteten Rolle Commit 0cb2af2ea66ad („KVM: x86: Fix shadow paging use-after-free due to unexpected GFN“) behob eine Inkonsistenz beim Shadow Paging zwischen gespeicherten und berechneten GFNs; der Fehler konnte ausgelöst werden, indem eine PDE-Zuordnung von außerhalb des Gasts geändert und anschließend ein Memslot gelöscht wurde. Der Aufruf von rmap_remove() würde Einträge übersehen, die nach der PDE-Änderung erstellt wurden, weil die GFN des Blatt-SPTE nicht mit der GFN der struct kvm_mmu_page übereinstimmt. Eine ähnliche Lücke bleibt jedoch bestehen, wenn die geänderte PDE auf eine Nicht-Blatt-Seite zeigt. In diesem Fall kann die GFN zur Übereinstimmung gebracht werden, aber die Rolle stimmt nicht überein: Die ursprüngliche große 2MB-Seite erstellt eine kvm_mmu_page mit direct=1, während die neue 4KB-Seite eine kvm_mmu_page mit direct=0 benötigt. kvm_mmu_get_child_sp() vergleicht die Rolle jedoch nicht und verwendet daher die Seite erneut. Der nächste Schritt besteht darin, ein Blatt-SPTE (4KB) auf dem neuen Pfad zu installieren, das einen rmap-Eintrag unter der durch den Walk aufgelösten GFN aufzeichnet. Wenn dieses Child jedoch entfernt wird, hat seine übergeordnete kvm_mmu_page direct=1 und kvm_mmu_page_get_gfn() berechnet die GFN für die 4KB-Seite als sp->gfn + index, anstatt sp->shadowed_translation[] (oder sp->gfns[] in älteren Kerneln) zu verwenden. Daher schlägt das Entfernen des aufgezeichneten Eintrags fehl. Wenn der Memslot entfernt wird, wird die Shadow-Seite freigegeben, aber der rmap- Eintrag bleibt bestehen, wie in dem bereits behobenen Szenario. Code, der später diese GFN durchläuft (Dirty Logging, MMU-Notifier-Invalidierung usw.), dereferenziert ein sptep, das in der freigegebenen Seite liegt, und verursacht dadurch den Use-after-free.