{"id":38417,"date":"2026-06-24T10:03:32","date_gmt":"2026-06-24T08:03:32","guid":{"rendered":"https:\/\/enginsight.com\/?p=38417"},"modified":"2026-06-24T10:05:11","modified_gmt":"2026-06-24T08:05:11","slug":"cve-2026-42945-nginx-rift-rce","status":"publish","type":"post","link":"https:\/\/enginsight.com\/de\/blog\/cve-2026-42945-nginx-rift-rce\/","title":{"rendered":"CVE-2026-42945 &#8211; NGINX CVE kann RCE erm\u00f6glichen"},"content":{"rendered":"<div class=\"wp-block-table-of-contents-block-table-of-contents-block\"><div class=\"eb-parent-wrapper eb-parent-eb-toc-4g6zz \"><div class=\"eb-toc-container eb-toc-4g6zz  eb-toc-is-not-sticky eb-toc-not-collapsible eb-toc-initially-not-collapsed eb-toc-scrollToTop style-1 list-style-none\" data-scroll-top=\"false\" data-scroll-top-icon=\"fas fa-angle-up\" data-collapsible=\"false\" data-sticky-hide-mobile=\"false\" data-sticky=\"false\" data-scroll-target=\"scroll_to_toc\" data-copy-link=\"false\" data-editor-type=\"\" data-hide-desktop=\"false\" data-hide-tab=\"false\" data-hide-mobile=\"false\" data-itemcollapsed=\"false\"><div class=\"eb-toc-header\"><div class=\"eb-toc-title\">Table of Contents<\/div><\/div><div class=\"eb-toc-wrapper \" data-headers='[{\"level\":1,\"content\":\"CVE-2026-42945 - NGINX CVE kann RCE erm\\u00f6glichen\",\"text\":\"CVE-2026-42945 - NGINX CVE kann RCE erm\\u00f6glichen\",\"link\":\"eb-table-content-0\"},{\"level\":2,\"content\":\"Ursprung der Schwachstelle\",\"text\":\"Ursprung der Schwachstelle\",\"link\":\"ursprung-der-schwachstelle\"},{\"level\":2,\"content\":\"Zusammenspiel zwischen CVE-2026-42945 und ASLR\",\"text\":\"Zusammenspiel zwischen CVE-2026-42945 und ASLR\",\"link\":\"zusammenspiel-zwischen-cve-2026-42945-und-aslr\"},{\"level\":2,\"content\":\"Nachstellung POC\",\"text\":\"Nachstellung POC\",\"link\":\"nachstellung-poc\"},{\"level\":3,\"content\":\"Erkl\\u00e4rung POC:\",\"text\":\"Erkl\\u00e4rung POC:\",\"link\":\"eb-table-content-4\"},{\"level\":4,\"content\":\"Phase 1 \\u2013 Vorbereitung des Heaps (Heap Spray)\",\"text\":\"Phase 1 \\u2013 Vorbereitung des Heaps (Heap Spray)\",\"link\":\"phase-1-vorbereitung-des-heaps-heap-spray\"},{\"level\":4,\"content\":\"Phase 2 \\u2013 Ausl\\u00f6sen des Buffer Overflows\",\"text\":\"Phase 2 \\u2013 Ausl\\u00f6sen des Buffer Overflows\",\"link\":\"eb-table-content-6\"},{\"level\":4,\"content\":\"Phase 3 \\u2013 Ausf\\u00fchrung und Validierung\",\"text\":\"Phase 3 \\u2013 Ausf\\u00fchrung und Validierung\",\"link\":\"eb-table-content-7\"},{\"level\":3,\"content\":\"Analyse der Logdaten:\",\"text\":\"Analyse der Logdaten:\",\"link\":\"analyse-der-logdaten\"},{\"level\":3,\"content\":\"Darstellung in Enginsight\",\"text\":\"Darstellung in Enginsight\",\"link\":\"darstellung-in-enginsight\"},{\"level\":3,\"content\":\"Ursachenanalyse\",\"text\":\"Ursachenanalyse\",\"link\":\"ursachenanalyse\"},{\"level\":3,\"content\":\"Fazit\",\"text\":\"Fazit\",\"link\":\"fazit\"}]' data-visible=\"[true,true,true,true,true,true]\" data-delete-headers='[{\"label\":\"CVE-2026-42945 - NGINX CVE kann RCE erm\\u00f6glichen\",\"value\":\"cve-2026-42945-nginx-cve-kann-rce-erm\\u00f6glichen\",\"isDelete\":false},{\"label\":\"Ursprung der Schwachstelle\",\"value\":\"ursprung-der-schwachstelle\",\"isDelete\":false},{\"label\":\"Zusammenspiel zwischen CVE-2026-42945 und ASLR\",\"value\":\"zusammenspiel-zwischen-cve-2026-42945-und-aslr\",\"isDelete\":false},{\"label\":\"Nachstellung POC\",\"value\":\"nachstellung-poc\",\"isDelete\":false},{\"label\":\"Erkl\\u00e4rung POC:\",\"value\":\"erkl\\u00e4rung-poc\",\"isDelete\":false},{\"label\":\"Phase 1 \\u2013 Vorbereitung des Heaps (Heap Spray)\",\"value\":\"phase-1-vorbereitung-des-heaps-heap-spray\",\"isDelete\":false},{\"label\":\"Phase 2 \\u2013 Ausl\\u00f6sen des Buffer Overflows\",\"value\":\"phase-2-ausl\\u00f6sen-des-buffer-overflows\",\"isDelete\":false},{\"label\":\"Phase 3 \\u2013 Ausf\\u00fchrung und Validierung\",\"value\":\"phase-3-ausf\\u00fchrung-und-validierung\",\"isDelete\":false},{\"label\":\"Analyse der Logdaten:\",\"value\":\"analyse-der-logdaten\",\"isDelete\":false},{\"label\":\"Darstellung in Enginsight\",\"value\":\"darstellung-in-enginsight\",\"isDelete\":false},{\"label\":\"Ursachenanalyse\",\"value\":\"ursachenanalyse\",\"isDelete\":false},{\"label\":\"Fazit\",\"value\":\"fazit\",\"isDelete\":false}]' data-smooth=\"true\" data-top-offset=\"\"><div class=\"eb-toc__list-wrap\"><ul class=\"eb-toc__list\"><li><a href=\"#eb-table-content-0\">CVE-2026-42945 &#x2013; NGINX CVE kann RCE erm&#xF6;glichen<\/a><ul class=\"eb-toc__list\"><li><a href=\"#ursprung-der-schwachstelle\">Ursprung der Schwachstelle<\/a><\/li><li><a href=\"#zusammenspiel-zwischen-cve-2026-42945-und-aslr\">Zusammenspiel zwischen CVE-2026-42945 und ASLR<\/a><\/li><li><a href=\"#nachstellung-poc\">Nachstellung POC<\/a><ul class=\"eb-toc__list\"><li><a href=\"#eb-table-content-4\">Erkl&#xE4;rung POC:<\/a><ul class=\"eb-toc__list\"><li><a href=\"#phase-1-vorbereitung-des-heaps-heap-spray\">Phase 1 &#x2013; Vorbereitung des Heaps (Heap Spray)<\/a><\/li><li><a href=\"#eb-table-content-6\">Phase 2 &#x2013; Ausl&#xF6;sen des Buffer Overflows<\/a><\/li><li><a href=\"#eb-table-content-7\">Phase 3 &#x2013; Ausf&#xFC;hrung und Validierung<\/a><\/li><\/ul><\/li><li><a href=\"#analyse-der-logdaten\">Analyse der Logdaten:<\/a><\/li><li><a href=\"#darstellung-in-enginsight\">Darstellung in Enginsight<\/a><\/li><li><a href=\"#ursachenanalyse\">Ursachenanalyse<\/a><\/li><li><a href=\"#fazit\">Fazit<\/a><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/div><\/div><\/div><\/div><\/div>\n\n\n<h1 class=\"wp-block-heading\">CVE-2026-42945 &#x2013; NGINX CVE kann RCE erm&#xF6;glichen<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Eine im Mai bekannt gewordene Sicherheitsl&#xFC;cke mit dem Namen <strong>&#x201E;NGINX Rift&#x201C;<\/strong> sorgt f&#xFC;r Aufmerksamkeit. Die Schwachstelle betrifft das <strong>ngx_http_rewrite_module<\/strong> von NGINX und ist besonders bemerkenswert, da sie bereits seit dem Jahr 2008 im Quellcode vorhanden ist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Ursprung der Schwachstelle<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Der Fehler befindet sich in der Datei <code>src\/http\/ngx_http_script.c<\/code> und betrifft nahezu alle NGINX-Versionen bis einschlie&#xDF;lich <strong>Version 1.30.0<\/strong>. Aufgrund der weiten Verbreitung von NGINX als Webserver, Reverse Proxy und Load Balancer hat die Sicherheitsl&#xFC;cke ein erhebliches Gef&#xE4;hrdungspotenzial.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Angreifer kann durch speziell pr&#xE4;parierte HTTP-Anfragen einen Worker-Prozess zum Absturz bringen oder unter bestimmten Bedingungen Remote Code Execution erreichen. Dies wird erreicht, indem geschriebenen Bytes kontrolliert und die Daten im Heap landen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Genau betroffen ist der Teil von NGINX, der Rewrite Regeln bearbeitet. Diese Regeln dienen dazu, die gesamte oder einen Teil der URL, die vom Client angefordert wurde, zu &#xE4;ndern. Grund daf&#xFC;r k&#xF6;nnte sein, den Clients mitzuteilen, dass sich der Standort der von ihnen gesuchten Ressourcen ge&#xE4;ndert hat. Neben der Steuerung des Seitenflusses in NGINX k&#xF6;nnen Rewrite-Regeln auch zur Optimierung von Ladezeiten, zur SEO-Verbesserung und zur einfachen Verwaltung von Weiterleitungen beitragen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die NGINXs Script Engine verarbeitet die <code>rewrite<\/code> Anweisungen in zwei Durchl&#xE4;ufen. Zun&#xE4;chst wird berechnet, wie viel Speicher n&#xF6;tig ist (Length-Pass). Im n&#xE4;chsten Schritt werden die Daten tats&#xE4;chlich geschrieben (Copy-Pass). Dabei m&#xFC;ssen beide Durchl&#xE4;ufe die gleiche L&#xE4;nge ergeben, was sie bei der Ausnutzung der Schwachstelle nicht tun.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ausnutzbar wird die Schwachstelle insbesondere dann, wenn Rewrite-Regeln unbenannte Captures wie <code>$1<\/code>, <code>$2<\/code> oder <code>$3<\/code> verwenden. Ein typisches Beispiel w&#xE4;re:<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\"><span style=\"color:#E91E8C\">rewrite<\/span> <span style=\"color:#22863A\">^\/api\/(.*)$<\/span> \/internal?id=<span style=\"color:#D46B08\">$1<\/span><span style=\"color:#0E7490\">;<\/span><\/div>\n<\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Hier wird das Capture <code>$1<\/code> in einer Ziel-URL verwendet, die ein Fragezeichen (<code>?<\/code>) enth&#xE4;lt. Die Kombination aus unbenannten Captures und einer Rewrite-Zeichenkette mit <code>?<\/code> aktiviert den fehlerhaften Verarbeitungspfad. Laut den Analysen tritt das Problem insbesondere dann auf, wenn auf dieselben Capture-Werte sp&#xE4;ter erneut in weiteren <code>rewrite<\/code>-, <code>if<\/code>&#x2013; oder <code>set<\/code>-Anweisungen zugegriffen wird. Die Konfiguration selbst ist dabei vollst&#xE4;ndig g&#xFC;ltig und wird von <code>nginx -t<\/code> ohne Fehlermeldungen akzeptiert, weshalb die Verwundbarkeit nicht durch die &#xFC;bliche Konfigurationspr&#xFC;fung erkannt werden kann.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die eigentliche Diskrepanz entsteht, sobald ein Rewrite-Replacement ein <code>?<\/code> enth&#xE4;lt. Hierbei setzt NGINX intern das Flag <code>is_args = 1<\/code>, welches anschlie&#xDF;end nicht mehr zur&#xFC;ckgesetzt wird. Im Length-Pass verwendet NGINX jedoch eine neue, separate Engine. Dort hat <code>is_args<\/code> noch den Wert <code>0<\/code>. Deshalb wird der Capture-Wert lediglich in seiner urspr&#xFC;nglichen Form vermessen. Hat der Wert beispielsweise eine L&#xE4;nge von 8 Byte, reserviert NGINX exakt 8 Byte Speicher daf&#xFC;r.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Danach folgt der Copy-Pass. Dieser l&#xE4;uft jedoch auf der Haupt-Engine, bei der <code>is_args<\/code> weiterhin auf <code>1<\/code> steht. Dadurch ruft NGINX die Funktion <code>ngx_escape_uri()<\/code> mit dem Flag <code>NGX_ESCAPE_ARGS<\/code> auf.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Diese Funktion maskiert bestimmte Sonderzeichen f&#xFC;r URL-Parameter. Zeichen wie <code>+<\/code>, <code>%<\/code> oder <code>&amp;<\/code> werden dabei von <strong>1 Byte auf 3 Byte<\/strong> erweitert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Da die Speichergr&#xF6;&#xDF;e vorher mit der urspr&#xFC;nglichen Gr&#xF6;&#xDF;e 8 Bytes berechnet wurde, ist es dem Angreifer m&#xF6;glich mehr Speicher zu beschreiben, als reserviert wurde, vorausgesetzt der kontrollierte URI-Teil enth&#xE4;lt mehrere solcher Sonderzeichen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Enth&#xE4;lt der URI beispielsweise drei Zeichen, die jeweils von einem auf drei Byte erweitert werden, entstehen zus&#xE4;tzlich sechs Byte Speicherbedarf (3 &#xD7; (3 &#x2212; 1)). NGINX schreibt dann insgesamt 14 Byte (8 urspr&#xFC;ngliche Byte plus 6 zus&#xE4;tzliche Byte) in einen Puffer, der lediglich 8 Byte gro&#xDF; ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dadurch entsteht ein Heap-Buffer-Overflow. Wobei nicht zuf&#xE4;llig Speicher &#xFC;berschrieben wird, denn direkt neben dem &#xFC;berlaufenden Puffer befindet sich h&#xE4;ufig eine Struktur vom Typ <code>ngx_pool_cleanup_t<\/code>. Diese enth&#xE4;lt unter anderem einen Pointer (<code>cleanup handler<\/code>). Ein Angreifer kann durch mehrere speziell vorbereitete Requests das Heap-Layout beeinflussen. Das Ziel ist dabei, den Speicher so anzuordnen, dass der Overflow genau den Funktionszeiger in einer benachbarten <code>ngx_pool_cleanup_t<\/code>-Struktur &#xFC;berschreibt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn NGINX sp&#xE4;ter die Verarbeitung des Requests beendet, wird der Request-Pool freigegeben. Dabei durchl&#xE4;uft NGINX die sogenannte Cleanup-Liste und ruft alle dort registrierten Cleanup-Handler auf.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wurde der Funktionszeiger zuvor &#xFC;berschrieben, f&#xFC;hrt NGINX nicht mehr die urspr&#xFC;nglich vorgesehene Funktion aus, sondern die vom Angreifer bestimmte Adresse. Im beschriebenen Exploit wird dadurch <code>system()<\/code> mit vom Angreifer kontrollierten Argumenten aufgerufen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das Ergebnis ist Remote Code Execution, also die Ausf&#xFC;hrung beliebiger Befehle auf dem betroffenen System.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Zusammenspiel zwischen CVE-2026-42945 und ASLR<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Address Space Layout Randomization (ASLR)<\/strong> ist ein Speicherschutzmechanismus moderner Betriebssysteme, der die Speicheradressen wichtiger Bereiche eines Prozesses bei jedem Programmstart zuf&#xE4;llig anordnet. Dazu geh&#xF6;ren unter anderem der Heap, der Stack, geladene Bibliotheken (z. B. libc) sowie ausf&#xFC;hrbarer Programmcode.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Da die Speicherbereiche bei jedem Prozessstart zuf&#xE4;llig gew&#xE4;hlt werden, kennt der Angreifer die tats&#xE4;chliche Adresse von <code>system()<\/code> oder anderen relevanten Codeabschnitten nicht. Selbst wenn es ihm gelingt, den Funktionszeiger zu &#xFC;berschreiben, w&#xFC;rde ein Sprung zu einer falschen Adresse in der Regel lediglich zum Absturz des NGINX-Workers f&#xFC;hren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Sicherheitsforscher von depthfirst beschreiben jedoch zus&#xE4;tzlich eine Technik, bei der der Angreifer Speicherinformationen schrittweise gewinnt und ASLR Byte f&#xFC;r Byte umgeht. Dadurch kann der Angriff trotz aktivierter Adressraum-Zufallisierung schlie&#xDF;lich erfolgreich werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Quelle: <a href=\"https:\/\/www.herodevs.com\/blog-posts\/cve-2026-42945-nginx-rift-heap-buffer-overflow-hits-ingress-nginx\" target=\"_blank\" rel=\"noopener\">https:\/\/www.herodevs.com\/blog-posts\/cve-2026-42945-nginx-rift-heap-buffer-overflow-hits-ingress-nginx<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Nachstellung POC<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r die Sicherheitsl&#xFC;cke existieren bereits &#xF6;ffentlich verf&#xFC;gbare PoCs, die einen funktionierenden Exploit demonstrieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">POC <a href=\"https:\/\/github.com\/F2u0a0d3\/CVE-2026-42945-nginx-rift-poc\" target=\"_blank\" rel=\"noopener\">https:\/\/github.com\/F2u0a0d3\/CVE-2026-42945-nginx-rift-poc<\/a><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dieser PoC wurde in einer Testumgebung nachgestellt und dabei mit dem Enginsight SIEM analysiert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r den Versuch wurde der im PoC enthaltene nginx-Docker-Container gestartet und das bereitgestellte Python-Skript ausgef&#xFC;hrt. Das Skript pr&#xE4;pariert den nginx-Heap mit einer gef&#xE4;lschten Datenstruktur, die einen manipulierten Funktionspointer enth&#xE4;lt. Anschlie&#xDF;end wird &#xFC;ber einen speziell konstruierten URL-Pfad ein Buffer Overflow ausgel&#xF6;st, der einen legitimen Funktionspointer im Heap &#xFC;berschreibt. Ziel ist es, dass nginx bei einem sp&#xE4;teren internen Funktionsaufruf statt des urspr&#xFC;nglichen Zeigers den manipulierten Pointer verwendet und dadurch die Funktion <code>system()<\/code> mit einem vom Angreifer kontrollierten Befehl ausf&#xFC;hrt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Erkl&#xE4;rung POC:<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Phase 1 &#x2013; Vorbereitung des Heaps (Heap Spray)<\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">Hierzu werden 20 parallele HTTP-Verbindungen aufgebaut, die jeweils einen 4000 Byte gro&#xDF;en POST-Request an den Endpunkt <code>\/spray<\/code> senden. Der Request-Body enth&#xE4;lt eine gef&#xE4;lschte Datenstruktur bestehend aus der Adresse von <code>system()<\/code>, einem Datenzeiger sowie dem auszuf&#xFC;hrenden Kommando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Durch die hohe Anzahl paralleler Verbindungen wird der Heap des nginx-Prozesses gezielt mit dieser Struktur bef&#xFC;llt (&#x201E;Heap Spray&#x201C;). Die Verbindungen bleiben mittels des Headers <code>X-Delay: 60<\/code> ge&#xF6;ffnet, sodass die reservierten Speicherbereiche nicht freigegeben werden und die manipulierten Strukturen im Speicher verbleiben.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Phase 2 &#x2013; Ausl&#xF6;sen des Buffer Overflows<\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">Ein einzelner GET-Request an <code>\/api\/<\/code> mit einem speziell konstruierten Payload &#xFC;berschreibt einen Funktionspointer innerhalb einer benachbarten Connection-Struktur im Heap.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Payload besteht aus einem Block von <code>A<\/code>-Zeichen, einem Block aus <code>+<\/code>-Zeichen sowie einer Zieladresse. Diese Zieladresse verweist auf eine der zuvor platzierten Fake-Strukturen aus Phase 1 (<code>HEAP_BASE + Offset<\/code>). Durch den Overflow wird der urspr&#xFC;ngliche Funktionspointer auf diese Adresse umgebogen.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Phase 3 &#x2013; Ausf&#xFC;hrung und Validierung<\/h4>\n\n\n\n<p class=\"wp-block-paragraph\">Nach dem &#xDC;berschreiben des Funktionspointers &#xFC;berpr&#xFC;ft das Skript, ob der betroffene nginx-Worker weiterhin reagiert oder abgest&#xFC;rzt ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Absturz deutet darauf hin, dass der Funktionspointer erfolgreich &#xFC;berschrieben wurde. Ob tats&#xE4;chlich ein Aufruf von <code>system()<\/code> erfolgt, h&#xE4;ngt davon ab, ob die verwendete Zieladresse exakt auf eine g&#xFC;ltige Fake-Struktur zeigt. Falls dies nicht der Fall ist, wird der n&#xE4;chste Offset aus der Liste <code>PREREAD_HEAP_OFFSETS<\/code> verwendet und der Vorgang erneut gestartet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Analyse der Logdaten:<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In den Logs sind folgende Ereignisse erkennbar:<\/p>\n\n\n\n<figure class=\"wp-block-gallery has-nested-images columns-default is-cropped wp-block-gallery-1 is-layout-flex wp-block-gallery-is-layout-flex\">\n<figure class=\"wp-block-image size-large\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"305\" data-id=\"38419\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/01-2-1024x305.png\" alt=\"\" class=\"wp-image-38419\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/01-2-1024x305.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/01-2-300x89.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/01-2-768x229.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/01-2-1536x457.png 1536w, https:\/\/enginsight.com\/wp-content\/uploads\/01-2.png 1925w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n<\/figure>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Rewrite-Match mit dem Payload<\/strong><\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Der Payload besteht aus drei Komponenten:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>349 &#xD7; &#x201E;A&#x201C;<\/strong><br>Dient als Padding und positioniert den Schreibzeiger des Overflows an die gew&#xFC;nschte Stelle im Heap.<\/li>\n\n\n\n<li><strong>969 &#xD7; &#x201E;+&#x201C;<\/strong><br>Dieser Teil triggert die eigentliche Schwachstelle. nginx reserviert den Speicher anhand der urspr&#xFC;nglichen L&#xE4;nge des Puffers, schreibt beim Dekodieren von <code>%2B<\/code> jedoch mehr Daten als vorgesehen. Dadurch entsteht der Buffer Overflow.<\/li>\n\n\n\n<li><strong>&#x201E;4kUUU&#x201C; (Adressbytes)<\/strong><br>Enth&#xE4;lt die Zieladresse als rohe, Latin-1-kodierte Bytes. Dabei handelt es sich um die sechs niederwertigen Bytes von <code>HEAP_BASE + Offset<\/code>, auf die der &#xFC;berschriebenen Funktionspointer sp&#xE4;ter zeigen soll.<\/li>\n\n\n\n<li><strong>Rewrite auf <\/strong><code>\/internal?migrated=true<\/code><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Der fehlerhafte Codepfad wird durchlaufen und der Overflow ausgel&#xF6;st.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Absturz des nginx-Workers<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Worker 9 beendet sich aufgrund eines Segmentation Faults (Signal 11) und erzeugt einen Core Dump.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Automatischer Neustart des Workers<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Der nginx-Masterprozess startet den abgest&#xFC;rzten Worker neu.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Darstellung in Enginsight<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In Enginsight besteht die M&#xF6;glichkeit, sowohl native nginx-Logs als auch die Logdaten von Docker-Containern direkt an das SIEM zu &#xFC;bertragen. Da der PoC innerhalb eines Docker-Containers ausgef&#xFC;hrt wurde, basiert die Analyse auf den erfassten Container-Logs. Die enthaltenen nginx-Logs werden dabei automatisch geparst und aufbereitet, sodass die f&#xFC;r den Exploit relevanten Ereignisse, insbesondere der Rewrite-Match sowie der anschlie&#xDF;ende Absturz des nginx-Workers, zentral erfasst und im SIEM nachvollzogen werden k&#xF6;nnen.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" width=\"718\" height=\"813\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/03-2.png\" alt=\"\" class=\"wp-image-38420\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/03-2.png 718w, https:\/\/enginsight.com\/wp-content\/uploads\/03-2-265x300.png 265w\" sizes=\"(max-width: 718px) 100vw, 718px\"\/><figcaption class=\"wp-element-caption\">Absturz Worker<\/figcaption><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" width=\"709\" height=\"555\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/06-1.png\" alt=\"\" class=\"wp-image-38421\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/06-1.png 709w, https:\/\/enginsight.com\/wp-content\/uploads\/06-1-300x235.png 300w\" sizes=\"(max-width: 709px) 100vw, 709px\"\/><figcaption class=\"wp-element-caption\">Rewrite Match<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Alarmierung in Enginsight:<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die beiden identifizierten SIEM-Ereignisse k&#xF6;nnen zur Erstellung einer Korrelationsregel genutzt werden, die einen Alarm ausl&#xF6;st, wenn unmittelbar nach einem Rewrite-Vorgang ein Absturz eines nginx-Workers festgestellt wird.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine solche Alarmierung ist sinnvoll, da die Kombination aus Rewrite-Aktivit&#xE4;t und anschlie&#xDF;endem Worker-Absturz auf einen m&#xF6;glichen Ausnutzungsversuch der beschriebenen Schwachstelle hindeuten kann. W&#xE4;hrend einzelne Rewrite-Operationen oder Worker-Neustarts im regul&#xE4;ren Betrieb auftreten k&#xF6;nnen, stellt das zeitliche Zusammentreffen beider Ereignisse ein auff&#xE4;lliges Muster dar, das auf die Ausf&#xFC;hrung eines Exploits oder einen fehlgeschlagenen Angriffsversuch schlie&#xDF;en l&#xE4;sst. Anbei wird gezeigt, wie die entsprechenden SIEM Streams auszusehen haben:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Regel Nummer 1: Rewrite Match<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\">nginx.message_str<span style=\"color:#0E7490\">:<\/span><span style=\"color:#22863A\">&#x201E;* rewritten data: *&#x201C;<\/span><\/div>\n<\/div>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"281\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/11-1024x281.png\" alt=\"\" class=\"wp-image-38430\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/11-1024x281.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/11-300x82.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/11-768x211.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/11.png 1305w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Achtung: F&#xFC;r diese Log muss das Log-Level des Error Logs auf <code>notice<\/code> stehen sowie das <code>rewrite-log<\/code> aktiviert sein. Das ist &#xFC;ber die nginx.conf m&#xF6;glich:<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\"><span style=\"color:#E91E8C\">error_log<\/span> \/dev\/stderr <span style=\"color:#B8860B\">notice<\/span><span style=\"color:#0E7490\">;<\/span><\/div>\n<\/div>\n\n\n\n<p class=\"wp-block-paragraph\"><code>http<\/code>&#x2013; oder <code>server<\/code> block<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\"><span style=\"color:#E91E8C\">rewrite_log<\/span> <span style=\"color:#B8860B\">on<\/span><span style=\"color:#0E7490\">;<\/span><\/div>\n<\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Regel Nummer 2: Worker Crash:<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\">nginx.type<span style=\"color:#0E7490\">:<\/span><span style=\"color:#22863A\">&#x201E;error log&#x201C;<\/span> <span style=\"color:#E91E8C\">AND<\/span> nginx.message_str<span style=\"color:#0E7490\">:<\/span><span style=\"color:#22863A\">&#x201E;*worker process* exited on signal*&#x201C;<\/span> <span style=\"color:#E91E8C\">AND<\/span> nginx.message_str<span style=\"color:#0E7490\">:<\/span><span style=\"color:#0891B2\">in<\/span>(<span style=\"color:#22863A\">&#x201E;*signal 11*&#x201C;<\/span><span style=\"color:#0E7490\">,<\/span> <span style=\"color:#22863A\">&#x201E;segfault&#x201C;<\/span>)<\/div>\n<\/div>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"237\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/07-1-1024x237.png\" alt=\"\" class=\"wp-image-38423\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/07-1-1024x237.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/07-1-300x69.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/07-1-768x178.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/07-1.png 1302w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Die zwei Streams k&#xF6;nnen genutzt werden, um einen Workflow, wie folgt, zu erstellen.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"563\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/09-1024x563.png\" alt=\"\" class=\"wp-image-38424\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/09-1024x563.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/09-300x165.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/09-768x422.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/09-1536x844.png 1536w, https:\/\/enginsight.com\/wp-content\/uploads\/09.png 1614w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Bei einer erneuten Ausf&#xFC;hrung des PoC ist erkennbar, dass der Workflow erfolgreich ausgel&#xF6;st wurde. Nach dem &#xD6;ffnen des entsprechenden Ereignisses l&#xE4;sst sich nachvollziehen, welche Aktivit&#xE4;t die Alarmierung verursacht hat und welche Ereignisse zur Ausl&#xF6;sung des Workflows gef&#xFC;hrt haben.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"40\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/grafik-7-1024x40.png\" alt=\"\" class=\"wp-image-38425\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/grafik-7-1024x40.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-7-300x12.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-7-768x30.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-7-1536x61.png 1536w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-7.png 1570w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"532\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/10-1024x532.png\" alt=\"\" class=\"wp-image-38426\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/10-1024x532.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/10-300x156.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/10-768x399.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/10-1536x798.png 1536w, https:\/\/enginsight.com\/wp-content\/uploads\/10.png 1615w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"360\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/08-1-1024x360.png\" alt=\"\" class=\"wp-image-38427\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/08-1-1024x360.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/08-1-300x105.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/08-1-768x270.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/08-1-1536x540.png 1536w, https:\/\/enginsight.com\/wp-content\/uploads\/08-1.png 1616w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Ursachenanalyse<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Der PoC demonstriert grunds&#xE4;tzlich die erfolgreiche Ausnutzung der Schwachstelle. Allerdings konnte im Test kein erfolgreicher Aufruf von <code>system()<\/code> beobachtet werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ursache hierf&#xFC;r ist die aktivierte Address Space Layout Randomization (ASLR). Die im PoC hinterlegten Speicheradressen entsprechen nicht der tats&#xE4;chlichen Laufzeitumgebung des Containers.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Im PoC wird beispielsweise folgende Heap-Basisadresse angenommen:<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\">HEAP_BASE <span style=\"color:#0E7490\">=<\/span> <span style=\"color:#D46B08\">0x555555659000<\/span><\/div>\n<\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Im Testcontainer befand sich der Heap jedoch bei:<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\">HEAP_BASE <span style=\"color:#0E7490\">=<\/span> <span style=\"color:#D46B08\">0x55555566f000<\/span><\/div>\n<\/div>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"974\" height=\"430\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/02-2.png\" alt=\"\" class=\"wp-image-38428\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/02-2.png 974w, https:\/\/enginsight.com\/wp-content\/uploads\/02-2-300x132.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/02-2-768x339.png 768w\" sizes=\"(max-width: 974px) 100vw, 974px\"\/><figcaption class=\"wp-element-caption\">Auslesen der Adressen<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Dadurch verweisen s&#xE4;mtliche im PoC hinterlegten <code>PREREAD_HEAP_OFFSETS<\/code> auf falsche Zieladressen. Der &#xFC;berschriebene Funktionspointer zeigt folglich nicht auf die pr&#xE4;parierte Datenstruktur, sondern auf ung&#xFC;ltige Speicherbereiche. Statt eines Aufrufs von <code>system()<\/code> resultiert dies in einem Absturz des nginx-Workers.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die verwendeten Offsets beschreiben lediglich den Abstand zwischen Heap-Basis und Zielstruktur. Dieser Abstand bleibt zwar unver&#xE4;ndert, aufgrund der verschobenen Heap-Basis m&#xFC;ssten die Offsets jedoch entsprechend angepasst werden, um wieder auf dieselbe absolute Speicheradresse zu zeigen.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"557\" height=\"353\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/04-1.png\" alt=\"\" class=\"wp-image-38429\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/04-1.png 557w, https:\/\/enginsight.com\/wp-content\/uploads\/04-1-300x190.png 300w\" sizes=\"(max-width: 557px) 100vw, 557px\"\/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Fazit<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Der nachgestellte PoC zeigt trotz des fehlgeschlagenen Aufrufs von <code>system()<\/code>, dass die zugrunde liegende Schwachstelle erfolgreich ausgenutzt werden kann. Das &#xDC;berschreiben eines Funktionspointers sowie der daraus resultierende Absturz des nginx-Workers belegen die technische Funktionsf&#xE4;higkeit des Exploits.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In Umgebungen ohne ASLR oder bei korrekter Anpassung der verwendeten Adressen w&#xE4;re grunds&#xE4;tzlich die Ausf&#xFC;hrung beliebiger Befehle denkbar. Dies k&#xF6;nnte im Erfolgsfall zur Erlangung einer Remote Shell und damit zu einer vollst&#xE4;ndigen Kompromittierung des betroffenen Systems f&#xFC;hren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE-2026-42945 &#x2013; NGINX CVE kann RCE erm&#xF6;glichen Eine im Mai bekannt gewordene Sicherheitsl&#xFC;cke mit dem Namen &#x201E;NGINX Rift&#x201C; sorgt f&#xFC;r Aufmerksamkeit. Die Schwachstelle betrifft das ngx_http_rewrite_module von NGINX und ist besonders bemerkenswert, da sie bereits seit dem Jahr 2008 im Quellcode vorhanden ist. Ursprung der Schwachstelle Der Fehler befindet sich in der Datei src\/http\/ngx_http_script.c und [&#x2026;]<\/p>\n","protected":false},"author":36,"featured_media":38434,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_eb_attr":"","footnotes":""},"categories":[334],"tags":[362,119],"class_list":["post-38417","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-schwachstellen","tag-aslr","tag-cve"],"_links":{"self":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38417","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/users\/36"}],"replies":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/comments?post=38417"}],"version-history":[{"count":4,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38417\/revisions"}],"predecessor-version":[{"id":38436,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38417\/revisions\/38436"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media\/38434"}],"wp:attachment":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media?parent=38417"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/categories?post=38417"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/tags?post=38417"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}