{"metadata": {"vulnerability": "CVE-2026-15176", "count": 67, "kinds": {"milestone": 14, "sighting": 14, "kev": 0, "other": 39}}, "data": [{"timestamp": "2026-07-08T22:14:15.972Z", "date_only": false, "value": "2026-07-08T22:14:15.972Z", "kind": "milestone", "label": "Reserved", "source": "cvelistv5", "record": "CVE-2026-15176", "field": "cveMetadata.dateReserved"}, {"timestamp": "2026-10-14T00:00:00Z", "date_only": true, "value": "2026-10-14", "kind": "milestone", "label": "Published", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1317", "record": "CERTFR-2026-AVI-1317", "field": "vendor_advisories.0.published_at"}, {"timestamp": "2026-10-14T00:00:00Z", "date_only": true, "value": "2026-10-14", "kind": "milestone", "label": "Published", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1341", "record": "CERTFR-2026-AVI-1341", "field": "vendor_advisories.0.published_at"}, {"timestamp": "2026-10-14T14:00:00Z", "date_only": false, "value": "2026-10-14T14:00:00.000Z", "kind": "other", "label": "Made public", "source": "cvelistv5 / f5", "record": "CVE-2026-15176", "field": "containers.cna.datePublic"}, {"timestamp": "2026-10-14T14:40:26.374Z", "date_only": false, "value": "2026-10-14T14:40:26.374Z", "kind": "milestone", "label": "Published", "source": "cvelistv5", "record": "CVE-2026-15176", "field": "cveMetadata.datePublished"}, {"timestamp": "2026-10-14T14:40:26.374Z", "date_only": false, "value": "2026-10-14T14:40:26.374000+00:00", "kind": "other", "label": "Release date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.0.release_date"}, {"timestamp": "2026-10-14T14:40:26.374Z", "date_only": false, "value": "2026-10-14T14:40:26.374Z", "kind": "other", "label": "Updated", "source": "cvelistv5 / f5", "record": "CVE-2026-15176", "field": "containers.cna.providerMetadata.dateUpdated"}, {"timestamp": "2026-10-14T14:40:26.740Z", "date_only": false, "value": "2026-10-14T14:40:26.740000+00:00", "kind": "other", "label": "Release date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.3.release_date"}, {"timestamp": "2026-10-14T14:40:27.487Z", "date_only": false, "value": "2026-10-14T14:40:27.487000+00:00", "kind": "other", "label": "Release date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.2.release_date"}, {"timestamp": "2026-10-14T14:40:28.955Z", "date_only": false, "value": "2026-10-14T14:40:28.955000+00:00", "kind": "other", "label": "Release date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.1.release_date"}, {"timestamp": "2026-10-14T14:51:01.008Z", "date_only": false, "value": "2026-10-14T14:51:01.008670+00:00", "kind": "other", "label": "Discovery date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.0.discovery_date"}, {"timestamp": "2026-10-14T14:51:32.715Z", "date_only": false, "value": "2026-10-14T14:51:32.715700+00:00", "kind": "other", "label": "Discovery date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.1.discovery_date"}, {"timestamp": "2026-10-14T14:52:20.558Z", "date_only": false, "value": "2026-10-14T14:52:20.558649+00:00", "kind": "other", "label": "Discovery date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.2.discovery_date"}, {"timestamp": "2026-10-14T14:53:01.952Z", "date_only": false, "value": "2026-10-14T14:53:01.952789+00:00", "kind": "other", "label": "Discovery date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.3.discovery_date"}, {"timestamp": "2026-10-14T15:17:19Z", "date_only": false, "value": "2026-10-14T15:17:19Z", "kind": "other", "label": "Nvd published at", "source": "github \u00b7 GHSA-CVV4-J4MX-W8Q5", "record": "GHSA-CVV4-J4MX-W8Q5", "field": "database_specific.nvd_published_at"}, {"timestamp": "2026-10-14T15:17:19.140Z", "date_only": false, "value": "2026-10-14T15:17:19.140", "kind": "milestone", "label": "Published", "source": "fkie_nvd \u00b7 FKIE_CVE-2026-15176", "record": "FKIE_CVE-2026-15176", "field": "published"}, {"timestamp": "2026-10-14T15:32:28Z", "date_only": false, "value": "2026-10-14T15:32:28Z", "kind": "milestone", "label": "Published", "source": "github \u00b7 GHSA-CVV4-J4MX-W8Q5", "record": "GHSA-CVV4-J4MX-W8Q5", "field": "published"}, {"timestamp": "2026-10-14T15:32:28Z", "date_only": false, "value": "2026-10-14T15:32:28Z", "kind": "other", "label": "Updated", "source": "github \u00b7 GHSA-CVV4-J4MX-W8Q5", "record": "GHSA-CVV4-J4MX-W8Q5", "field": "modified"}, {"timestamp": "2026-10-14T15:52:30.364Z", "date_only": false, "value": "2026-10-14T15:52:30.364976Z", "kind": "sighting", "label": "Seen", "source": "https://bsky.app/profile/securityonline.bsky.social/post/3mxtvplbz7y2t", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "8af46822-8f27-43f8-9a28-f05eaedb012d", "content": "F5 patched three NGINX vulnerabilities (CVE-2026-97205, CVE-2026-93479, CVE-2026-15176) rated 9.2 Critical in F5 NGINX Plus and Open Source. Upgrade today.\n\n#NGINX #F5Networks #CVE202697205 #CVE202693479 #CVE202615176 #Cybersecurity #InfoSec", "url": "https://bsky.app/profile/securityonline.bsky.social/post/3mxtvplbz7y2t"}, {"timestamp": "2026-10-14T16:10:33.128Z", "date_only": false, "value": "2026-10-14T16:10:33.128110Z", "kind": "sighting", "label": "Seen", "source": "https://bsky.app/profile/stemshop.bsky.social/post/3mxtwpuoeqh22", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "122827c7-fae7-41de-8ddd-3fdf4ae986da", "content": "\ud83d\udea8 CVE-2026-15176 \u2014 CVSS 9.2 CRITICAL\n\nA vulnerability exists in NGINX Plus and NGINX Open Source when a location is configured that uses the alia...\n\n\ud83d\udd0e https://stemshop.top/cve/CVE-2026-15176\n\n#CVE #CyberSecurity #InfoSec", "url": "https://bsky.app/profile/stemshop.bsky.social/post/3mxtwpuoeqh22"}, {"timestamp": "2026-10-14T17:20:04.813Z", "date_only": false, "value": "2026-10-14T17:20:04.813993Z", "kind": "sighting", "label": "Seen", "source": "https://bsky.app/profile/stackflag.bsky.social/post/3mxu2m73s5422", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "c1cec7cb-22c8-4b4e-8977-0a7c913a31aa", "content": "CVE-2026-15176 - nginx plus\nBoth NGINX Plus and the open\u2011source version can be forced to stop working or run unwanted code when a web rule uses the alias feature together with certain rewrite or logging\u2026\n\nToo many irrelevant or confusing CVEs? Use stackflag.com\n\n#nginxplus #f5 #CVE #infosec", "url": "https://bsky.app/profile/stackflag.bsky.social/post/3mxu2m73s5422"}, {"timestamp": "2026-10-14T20:11:11.700Z", "date_only": false, "value": "2026-10-14T20:11:11.700869Z", "kind": "sighting", "label": "Seen", "source": "https://infosec.exchange/users/cve/statuses/117441079979334912", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "5d35dce7-2b80-464c-943b-6136b3a2df89", "content": "CVE-2026-15176 NGINX ngx_http_core_module vulnerability A vulnerability exists in NGINX Plus and NGINX Open Source when a location is configured that uses the alias directive together with rewrite and a set or return directive referencing the $request_filename variable. Alternatively, the same result could be achieved when the $request_filename variable is used in an access log format directive. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.\nImpact:This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only.\nNote: Software versions which have reached End of Technical Support (EoTS) are not evaluated.\nhttps://www.cve.org/CVERecord?id=CVE-2026-15176https://my.f5.com/manage/s/article/K000162416#F5 #NGINXPlus #NGINXOpenSource#CVE_2026_15176#bot", "url": "https://infosec.exchange/users/cve/statuses/117441079979334912"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00Z", "kind": "other", "label": "Advisory revision", "source": "csaf_opensuse \u00b7 OPENSUSE-SU-2026:12143-1", "record": "OPENSUSE-SU-2026:12143-1", "field": "document.tracking.revision_history.0.date"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00Z", "kind": "other", "label": "Date", "source": "csaf_opensuse \u00b7 OPENSUSE-SU-2026:12143-1", "record": "OPENSUSE-SU-2026:12143-1", "field": "vulnerabilities.0.threats.0.date"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00Z", "kind": "other", "label": "Document generated", "source": "csaf_opensuse \u00b7 OPENSUSE-SU-2026:12143-1", "record": "OPENSUSE-SU-2026:12143-1", "field": "document.tracking.generator.date"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00", "kind": "other", "label": "Last revision date", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1317", "record": "CERTFR-2026-AVI-1317", "field": "last_revision_date"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00", "kind": "milestone", "label": "Published", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1317", "record": "CERTFR-2026-AVI-1317", "field": "initial_release_date"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00Z", "kind": "milestone", "label": "Published", "source": "csaf_opensuse \u00b7 OPENSUSE-SU-2026:12143-1", "record": "OPENSUSE-SU-2026:12143-1", "field": "document.tracking.initial_release_date"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00Z", "kind": "milestone", "label": "Published", "source": "osv_ubuntu \u00b7 UBUNTU-CVE-2026-15176", "record": "UBUNTU-CVE-2026-15176", "field": "published"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00.000000", "kind": "other", "label": "Revision date", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1317", "record": "CERTFR-2026-AVI-1317", "field": "revisions.0.revision_date"}, {"timestamp": "2026-10-15T00:00:00Z", "date_only": false, "value": "2026-10-15T00:00:00Z", "kind": "other", "label": "Updated", "source": "osv_ubuntu \u00b7 UBUNTU-CVE-2026-15176", "record": "UBUNTU-CVE-2026-15176", "field": "modified"}, {"timestamp": "2026-10-15T02:42:54Z", "date_only": false, "value": "2026-10-15T02:42:54+00:00", "kind": "other", "label": "Advisory revision", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "document.tracking.revision_history.0.date"}, {"timestamp": "2026-10-15T02:42:54Z", "date_only": false, "value": "2026-10-15T02:42:54+00:00", "kind": "other", "label": "Date", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "vulnerabilities.0.remediations.0.date"}, {"timestamp": "2026-10-15T02:42:54Z", "date_only": false, "value": "2026-10-15T02:42:54+00:00", "kind": "milestone", "label": "Published", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "document.tracking.initial_release_date"}, {"timestamp": "2026-10-15T03:56:59.608Z", "date_only": false, "value": "2026-10-15T03:56:59.608538Z", "kind": "other", "label": "Recorded", "source": "cvelistv5 / CISA-ADP", "record": "CVE-2026-15176", "field": "containers.adp.0.metrics.0.other.content.timestamp"}, {"timestamp": "2026-10-15T03:56:59.608Z", "date_only": false, "value": "2026-10-15T03:56:59.608538Z", "kind": "other", "label": "Recorded", "source": "fkie_nvd \u00b7 FKIE_CVE-2026-15176", "record": "FKIE_CVE-2026-15176", "field": "metrics.ssvcV203.0.ssvcData.timestamp"}, {"timestamp": "2026-10-15T10:31:15.809Z", "date_only": false, "value": "2026-10-15T10:31:15.809Z", "kind": "other", "label": "Updated", "source": "cvelistv5", "record": "CVE-2026-15176", "field": "cveMetadata.dateUpdated"}, {"timestamp": "2026-10-15T10:31:15.809Z", "date_only": false, "value": "2026-10-15T10:31:15.809Z", "kind": "other", "label": "Updated", "source": "cvelistv5 / CISA-ADP", "record": "CVE-2026-15176", "field": "containers.adp.0.providerMetadata.dateUpdated"}, {"timestamp": "2026-10-15T11:17:28.110Z", "date_only": false, "value": "2026-10-15T11:17:28.110", "kind": "other", "label": "Updated", "source": "fkie_nvd \u00b7 FKIE_CVE-2026-15176", "record": "FKIE_CVE-2026-15176", "field": "lastModified"}, {"timestamp": "2026-10-15T11:20:30Z", "date_only": false, "value": "2026-10-15T11:20:30.000000Z", "kind": "sighting", "label": "Seen", "source": "https://cyber.gc.ca/en/alerts-advisories/f5-security-advisory-av26-1049", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "5f6a2960-f45a-4423-9010-e18fddaefbc8", "url": "https://cyber.gc.ca/en/alerts-advisories/f5-security-advisory-av26-1049"}, {"timestamp": "2026-10-16T07:25:30.469Z", "date_only": false, "value": "2026-10-16T07:25:30.469051Z", "kind": "sighting", "label": "Seen", "source": "https://bsky.app/profile/cybowl.bsky.social/post/3mxy2cu53kf2v", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "b620d4ed-caba-4977-b128-1373e3356ec5", "content": "Vuln\u00e9rabilit\u00e9s critiques (CVSS \u2265 9) (suite)\n\u2022 NGINX (ngx http core module) (CVE-2026-15176), CVSS 9.2 (Cyberveille Esant\u00e9)", "url": "https://bsky.app/profile/cybowl.bsky.social/post/3mxy2cu53kf2v"}, {"timestamp": "2026-10-16T09:51:37Z", "date_only": false, "value": "2026-10-16T09:51:37Z", "kind": "other", "label": "Advisory revision", "source": "csaf_opensuse \u00b7 OPENSUSE-SU-2026:12143-1", "record": "OPENSUSE-SU-2026:12143-1", "field": "document.tracking.revision_history.1.date"}, {"timestamp": "2026-10-16T09:51:37Z", "date_only": false, "value": "2026-10-16T09:51:37Z", "kind": "other", "label": "Updated", "source": "csaf_opensuse \u00b7 OPENSUSE-SU-2026:12143-1", "record": "OPENSUSE-SU-2026:12143-1", "field": "document.tracking.current_release_date"}, {"timestamp": "2026-10-16T13:58:03.096Z", "date_only": false, "value": "2026-10-16T13:58:03.096558Z", "kind": "sighting", "label": "Seen", "source": "https://poliverso.org/objects/0477a01e-a29693b2-322e7ea838c0fc3e", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "1abe847f-99ba-46f7-89b6-51d1159a086a", "content": "F5 addressed multiple vulnerabilities, including critical RCE flaws in NGINX that attackers could exploit without authentication. Security and application delivery firm F5 announced fixes for eleven security issues in NGINX. Among them, critical vulnerabilities tracked as CVE-2026-15176 and CVE-2026-93479 could be exploited without authentication via crafted HTTP requests. Under certain conditions beyond their control, an [\u2026]F5 addressed critical RCE flaws in NGINX", "url": "https://poliverso.org/objects/0477a01e-a29693b2-322e7ea838c0fc3e"}, {"timestamp": "2026-10-16T13:58:34.060Z", "date_only": false, "value": "2026-10-16T13:58:34.060245Z", "kind": "sighting", "label": "Seen", "source": "https://bsky.app/profile/cybersecurity.poliverso.org.ap.brid.gy/post/3mxyqaxqjgbh2", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "e23e731c-3d78-4f72-8054-34bd55a4b217", "content": "F5 addressed multiple vulnerabilities, including critical RCE flaws in NGINX that attackers could exploit without authentication. Security and application delivery firm F5 announced fixes for eleven security issues in NGINX. Among them, critical vulnerabilities tracked as CVE-2026-15176 and [\u2026]", "url": "https://bsky.app/profile/cybersecurity.poliverso.org.ap.brid.gy/post/3mxyqaxqjgbh2"}, {"timestamp": "2026-10-17T01:07:37Z", "date_only": false, "value": "2026-10-17T01:07:37.000Z", "kind": "other", "label": "Advisory revision", "source": "csaf_microsoft \u00b7 MSRC_CVE-2026-15176", "record": "MSRC_CVE-2026-15176", "field": "document.tracking.revision_history.0.date"}, {"timestamp": "2026-10-17T01:07:37Z", "date_only": false, "value": "2026-10-17T01:07:37.000Z", "kind": "other", "label": "Date", "source": "csaf_microsoft \u00b7 MSRC_CVE-2026-15176", "record": "MSRC_CVE-2026-15176", "field": "vulnerabilities.0.remediations.0.date"}, {"timestamp": "2026-10-17T01:07:37Z", "date_only": false, "value": "2026-10-17T01:07:37.000Z", "kind": "milestone", "label": "Published", "source": "csaf_microsoft \u00b7 MSRC_CVE-2026-15176", "record": "MSRC_CVE-2026-15176", "field": "document.tracking.initial_release_date"}, {"timestamp": "2026-10-17T01:07:37Z", "date_only": false, "value": "2026-10-17T01:07:37.000Z", "kind": "other", "label": "Updated", "source": "csaf_microsoft \u00b7 MSRC_CVE-2026-15176", "record": "MSRC_CVE-2026-15176", "field": "document.tracking.current_release_date"}, {"timestamp": "2026-10-17T06:05:41.395Z", "date_only": false, "value": "2026-10-17T06:05:41.395901Z", "kind": "milestone", "label": "Published", "source": "osv_bellsoft \u00b7 BELL-CVE-2026-15176", "record": "BELL-CVE-2026-15176", "field": "published"}, {"timestamp": "2026-10-17T07:00:38.101Z", "date_only": false, "value": "2026-10-17T07:00:38.101Z", "kind": "other", "label": "Document generated", "source": "csaf_microsoft \u00b7 MSRC_CVE-2026-15176", "record": "MSRC_CVE-2026-15176", "field": "document.tracking.generator.date"}, {"timestamp": "2026-10-19T00:00:00Z", "date_only": false, "value": "2026-10-19T00:00:00", "kind": "other", "label": "Last revision date", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1341", "record": "CERTFR-2026-AVI-1341", "field": "last_revision_date"}, {"timestamp": "2026-10-19T00:00:00Z", "date_only": false, "value": "2026-10-19T00:00:00", "kind": "milestone", "label": "Published", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1341", "record": "CERTFR-2026-AVI-1341", "field": "initial_release_date"}, {"timestamp": "2026-10-19T00:00:00Z", "date_only": false, "value": "2026-10-19T00:00:00.000000", "kind": "other", "label": "Revision date", "source": "certfr_avis \u00b7 CERTFR-2026-AVI-1341", "record": "CERTFR-2026-AVI-1341", "field": "revisions.0.revision_date"}, {"timestamp": "2026-10-19T02:08:55Z", "date_only": false, "value": "2026-10-19T02:08:55.000000Z", "kind": "sighting", "label": "Seen", "source": "https://www.cert.dk/news/2026-10-19/F5-og-Juniper-lukker-kritiske-saarbarheder", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "eeaf114c-255e-4416-b11b-c640c7e22413", "url": "https://www.cert.dk/news/2026-10-19/F5-og-Juniper-lukker-kritiske-saarbarheder"}, {"timestamp": "2026-10-19T06:27:50Z", "date_only": false, "value": "2026-10-19T06:27:50.000000Z", "kind": "sighting", "label": "Seen", "source": "https://ccb.belgium.be/advisories/warning-heap-based-buffer-overflows-nginx-plus-and-nginx-open-source-can-be-exploited", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "52297717-ecec-41a7-8c87-cb8e81ddc235", "url": "https://ccb.belgium.be/advisories/warning-heap-based-buffer-overflows-nginx-plus-and-nginx-open-source-can-be-exploited"}, {"timestamp": "2026-10-19T11:48:54Z", "date_only": false, "value": "2026-10-19T11:48:54+00:00", "kind": "other", "label": "Advisory revision", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "document.tracking.revision_history.1.date"}, {"timestamp": "2026-10-20T04:11:04Z", "date_only": false, "value": "2026-10-20T04:11:04+00:00", "kind": "other", "label": "Advisory revision", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "document.tracking.revision_history.2.date"}, {"timestamp": "2026-10-20T04:11:04Z", "date_only": false, "value": "2026-10-20T04:11:04+00:00", "kind": "other", "label": "Document generated", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "document.tracking.generator.date"}, {"timestamp": "2026-10-20T04:11:04Z", "date_only": false, "value": "2026-10-20T04:11:04+00:00", "kind": "other", "label": "Updated", "source": "csaf_redhat \u00b7 RHSA-2026:83427", "record": "RHSA-2026:83427", "field": "document.tracking.current_release_date"}, {"timestamp": "2026-10-20T07:06:20Z", "date_only": false, "value": "2026-10-20T07:06:20.000000Z", "kind": "sighting", "label": "Seen", "source": "https://threatintel.cc/2026/10/20/f-releases-outofband-patches-for.html", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "ea620484-9225-4081-bd4c-0cad563561bc", "content": "F5 releases out-of-band patches for critical NGINX vulnerabilities\n\nF5 has released out-of-band security patches for multiple NGINX flaws, including three critical vulnerabilities in the ngx_http_v3_module (CVE-2026-15176 and CVE-2026-97205) and the NGINX map directive (CVE-2026-93479), BleepingComputer reports. Unprivileged remote attackers can exploit them for denial of service or, in some configurations, code execution via heap-based buffer overflow or use-after-free in the NGINX worker process; F5 has not flagged them as exploited in the wild.", "url": "https://threatintel.cc/2026/10/20/f-releases-outofband-patches-for.html"}, {"timestamp": "2026-10-20T09:06:51.375Z", "date_only": false, "value": "2026-10-20T09:06:51.375763Z", "kind": "sighting", "label": "Seen", "source": "https://infosec.exchange/users/edwardk/statuses/117472441730194321", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "9f99b05e-8d4d-4aae-9858-1b94b0f5cc74", "content": "F5 releases out-of-band patches for critical NGINX vulnerabilities\nF5 has released out-of-band security patches for multiple NGINX flaws, including three critical vulnerabilities in the ngx_http_v3_module (CVE-2026-15176 and CVE-2026-97205) and the NGINX map directive (CVE-2026-93479), BleepingComputer reports. Unprivileged remote attackers can exploit them for denial of service or, in some configurations, code execution via heap-based buffer overflow or use-after-free in the NGINX worker process; F5 has not flagged them as exploited in the wild. https://www.bleepingcomputer.com/news/security/f5-releases-out-of-band-patches-for-critical-nginx-vulnerabilities/", "url": "https://infosec.exchange/users/edwardk/statuses/117472441730194321"}, {"timestamp": "2026-10-21T08:53:28.604Z", "date_only": false, "value": "2026-10-21T08:53:28.604Z", "kind": "milestone", "label": "Published", "source": "bitnami_vulndb \u00b7 BIT-NGINX-2026-15176", "record": "BIT-NGINX-2026-15176", "field": "published"}, {"timestamp": "2026-10-21T09:15:38.550Z", "date_only": false, "value": "2026-10-21T09:15:38.550Z", "kind": "other", "label": "Updated", "source": "bitnami_vulndb \u00b7 BIT-NGINX-2026-15176", "record": "BIT-NGINX-2026-15176", "field": "modified"}, {"timestamp": "2026-10-22T06:03:21.253Z", "date_only": false, "value": "2026-10-22T06:03:21.253715Z", "kind": "other", "label": "Updated", "source": "osv_bellsoft \u00b7 BELL-CVE-2026-15176", "record": "BELL-CVE-2026-15176", "field": "modified"}, {"timestamp": "2026-10-22T16:24:59Z", "date_only": false, "value": "2026-10-22T16:24:59.000000Z", "kind": "sighting", "label": "Seen", "source": "https://gist.github.com/dansku/2132d01a7fc33e91ea57ff36e5c85fd0", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "3a128845-2f6f-4851-93dc-f6cd5e20d94e", "content": "## Role and rules\nYou are doing a read-only security assessment of this server against the October 2026 security releases for PHP, Node.js, Go and NGINX (reference data below). The server has several Linux users, one Laravel app and some other services. I believe PHP was already upgraded, but I am not sure whether manual configuration, multiple installed versions, or long-running processes mean the old code is still live. Your job is to find out what is actually running, not what should be running.\n\nHard rules:\n- DO NOT change anything. No package installs, upgrades or removals, no `apt update`, no restarts, reloads or kills, no config edits, no container pulls, rebuilds or restarts, no composer/npm installs.\n- Read-only commands only. Run `sudo -n true` first. If sudo needs a password, do not wait on it; proceed without root and list every blocked check under Gaps. Never run a command that waits for interactive input.\n- Only run `--version` on binaries that come from a known package (`dpkg -S`), a known version manager (nvm, asdf, mise, volta, fnm, n) or an official container image. For anything else use `file`, `strings` and `sha256sum` only. Never execute unknown files.\n- Never start containers. For stopped containers use `docker inspect`, `docker image inspect` and `docker history` only. `docker exec` into running containers is allowed for read-only commands.\n- Keep load low: prefix scans with `nice -n 19 ionice -c3`, use `find -xdev`, and limit scans to /usr, /opt, /srv, /var/www, /home, /root, /etc and Docker volume paths. No `find /`.\n- Trim output (`| head -50`, `| tail -50`). Save raw command output to $EVIDENCE_DIR and write the report incrementally after each section so nothing is lost if you run out of context.\n- Do not print secrets. When you read `.env` files, configs or environment variables, redact values; only note which keys exist if relevant.\n- Record all times with timezone. `ps lstart` and dpkg.log are local time; do not mix them with UTC.\n- The only things you create are $REPORT_PATH and $EVIDENCE_DIR.\n- If you have network access, you may read the primary advisories listed at the end to confirm version ranges and backport details. Do not send any data from this server anywhere.\n\n## Reference data\nPHP: CVE-2026-109618 and CVE-2026-109619, both critical unauthenticated RCE in request handling (cleanup after out-of-memory, and stale request state after free). Fixed in 8.5.12, 8.4.27, 8.3.36, 8.2.35. 8.1 and older are EOL upstream and need a confirmed vendor backport. Only updating is a complete fix, and every serving process must be restarted.\nNode.js: 21 Oct security release (DNS NUL truncation, TLS hostname verification bypasses, Brotli decoder out-of-bounds write/RCE, plus medium/low issues). Fixed in 22.23.4, 24.22.1, 26.12.1. EOL lines are affected.\nGo: CVE-2026-111943 / GO-2026-6809, crypto/x509 now rejects chains through selected untrusted intermediates. Fixed in 1.27.3 and 1.26.10. Binaries must be rebuilt; a toolchain upgrade does not change existing binaries.\nNGINX: multiple October advisories. Upstream fixed in 1.30.6+ and 1.31.7+, distro packages may backport under older version strings. Configuration-dependent issues: CVE-2026-15176 (`alias` + `rewrite` with `$request_filename` in certain directives), CVE-2026-93479 (script evaluation buffer overflow), CVE-2026-97205 (use-after-free with async file I/O and certain SSI handling), CVE-2026-95101 (HTTP/3 request body injection), CVE-2026-97629 (TLS session forgery). NGINX Proxy Manager (NPM) bundles its own NGINX/OpenResty; its app version does not tell you the NGINX build.\n\n## What to investigate\n\n### 0. Baseline\n- OS, distro release, kernel, uptime, package sources (apt sources including PPAs like ondrej/php or sury, nodesource, etc.).\n- All human and service users with a login shell or a home directory. You will check each one in the steps below.\n- What listens on the network: `ss -tulpn`, mapped to process, user and binary. Firewall state (`ufw status verbose`, `iptables -S`, `nft list ruleset`) to decide what is actually internet-facing.\n- Docker/Podman: running and stopped containers, image tags and digests, exposed ports, compose files and where they live.\n- systemd units (system and per-user), cron (system and every user's crontab via `crontab -l -u`), supervisor configs, pm2 per user.\n\n### 1. PHP (highest priority)\n1.0 Establish what was upgraded and when, before anything else:\n- /var/log/apt/history.log*, /var/log/dpkg.log*, /var/log/unattended-upgrades/. Note the exact install timestamp of every php* and nginx* package. This is the reference time for every \"process started before patch\" check below.\n- Run `needrestart -r l`, `checkrestart` and `sudo lsof +L1` if available. Any PHP, NGINX, Node or Go process holding deleted files is running unpatched code; list them all with PID, user, command and start time.\n- Find unmerged or stale config: `find /etc -xdev \\( -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.ucf-dist' \\)`, and check /etc/php/*/fpm/pool.d/ for pools belonging to PHP versions that should no longer serve traffic.\n\n1.1 Binaries on disk:\n- Every PHP binary: `/usr/bin/php*`, `/usr/sbin/php-fpm*`, `/usr/local/bin`, `/opt`, `update-alternatives --display php`, phpbrew/asdf/mise/custom builds in any home directory, and PHP inside containers (`docker exec  php -v`).\n- For each: exact version, which package provides it (`dpkg -S`, `dpkg -l | grep php`), and whether that package is the patched one. If the version string looks old, check the package changelog (`zcat /usr/share/doc//changelog.Debian.gz | head -50`) for the CVE IDs to confirm a backport.\n\n1.2 Running processes:\n- Every running PHP process: PHP-FPM masters and pools, Apache mod_php, php-cgi, FrankenPHP, RoadRunner/Octane, Swoole, queue workers, Horizon, schedulers, long-running artisan commands. For each PID record: user, start time (`ps -eo pid,user,lstart,cmd`), and the binary it is actually running (`ls -l /proc//exe`). A \"(deleted)\" target, or a start time earlier than the package install time from 1.0, means the process is still running the old unpatched code. This is the key check.\n\n1.3 Vhost to runtime mapping:\n- Produce a table: vhost/server_name \u2192 `fastcgi_pass` / `SetHandler` / proxy target \u2192 FPM pool file \u2192 FPM master PID and version. Any vhost pointing at an old socket, or at an FPM master not on a fixed version, is a finding.\n\n1.4 Applications:\n- Laravel app: location, owning user, `composer.json` PHP constraint, how it is served (FPM, Octane, container), its queue/scheduler workers and which binary they use. Note the deployment method (git pull, Envoyer, Forge, Deployer, Docker).\n- Any other PHP apps or tools (phpMyAdmin, WordPress, monitoring panels, control panels like Plesk/cPanel/Virtualmin/Forge agent).\n- Temporary mitigations in place, if any, from the PHP advisory (note them, do not treat them as a fix).\n\n### 2. Node.js\n- Every node binary: system packages, nodesource, `/usr/local`, nvm/fnm/volta/n/asdf/mise in every user's home, node inside containers, Single Executable Applications (only if cheap to detect).\n- Running node processes (pm2, systemd, containers): user, version via `/proc//exe --version` (allowed because it is a known runtime), start time, what they serve, whether internet-facing.\n- Flag build-only usage separately (e.g. Laravel Vite builds) from long-running services. Build-only is lower risk but still note it.\n- For running services, note if they handle attacker-controlled Brotli input, use `dns.resolve`, make outbound TLS calls, or use the permission model or snapshots.\n\n### 3. Go\n- Go toolchains installed (any user, `/usr/local/go`, asdf, mise, etc.).\n- Go binaries actually running or deployed: use `go version ` or `go version -m ` if a toolchain exists, otherwise `strings  | grep -m1 -E '^go1\\.[0-9]+'`. Check listening services, `/usr/local/bin`, `/opt`, home dirs, and container entrypoints.\n- Classify each as: built by us (we must rebuild), or vendor-provided (docker, containerd, runc, caddy, traefik, prometheus exporters, etc.: patch comes from the vendor package/image).\n- Note which ones make outbound TLS connections and to what, since the fix can break chains through the denylisted intermediates.\n\n### 4. NGINX and NGINX Proxy Manager\n- Host NGINX: `nginx -V` (full build info), package name and version, vendor changelog check for the October CVEs, master/worker start times vs package install time, `/proc//exe` target.\n- NPM or any other NGINX/OpenResty in containers: `docker exec  nginx -V` or `openresty -V`, image tag and digest, NPM app version (recorded separately from the NGINX build).\n- Configuration exposure (grep all configs, including NPM's generated configs inside its data volume, usually `data/nginx/proxy_host/*.conf`): `alias` combined with `rewrite` and `$request_filename`; `ssi on`; `aio` / `aio threads`; `listen ... quic` or `http3`; TLS session tickets/cache settings. Report which risky combinations exist, with file and line.\n\n### 5. Log and compromise review (window: $LOG_WINDOW_START to now)\n- PHP-FPM and PHP error logs: segfaults, \"exited on signal\", \"Allowed memory size ... exhausted\" spikes, unusual pool restarts.\n- NGINX/Apache error and access logs: worker crashes (signal 11), very large or malformed requests, unusual 5xx bursts, odd paths or user agents hitting PHP endpoints.\n- `journalctl -k` and `dmesg` for segfaults and OOM kills.\n- Light compromise indicators, read-only: recently modified PHP files in web roots and writable dirs (`storage/`, `public/`, uploads, `/tmp`), unexpected PHP files in upload dirs, new cron entries, new users or SSH keys (`authorized_keys` mtimes), unexpected outbound connections in `ss -tnp`.\n- Say exactly which logs you reviewed and their date coverage (rotated logs may limit the window).\n\n## Report format ($REPORT_PATH, Markdown)\n1. Executive summary: overall risk verdict, then one line per runtime (PHP, Node, Go, NGINX) with status: Patched and live / Patched on disk but old process still running / Not patched / Not present / Unknown.\n2. Internet exposure map: listening port, process, user, runtime and version, exposed publicly yes/no.\n3. Inventory table per runtime: location, owner/user, version, package or image, backport confirmed (yes/no/unknown), running processes using it, start time vs patch install time, status.\n4. The vhost \u2192 socket \u2192 pool \u2192 FPM version table from 1.3.\n5. Findings ordered by severity, each with the evidence (command and trimmed output, secrets redacted) and why it matters.\n6. NGINX configuration exposure details.\n7. Log and compromise review: what was checked, time window, anything suspicious.\n8. Recommended remediation steps, in priority order, written as exact commands I could run later. Do not run them.\n9. Gaps: what you could not check and why (permissions, missing tools, no network), and how I can close each gap.\n\nBe explicit about confidence. Never mark something as patched based only on a version file, a composer constraint or a CLI `php -v`; it counts only if the live process or binary is verified.\n\n## Primary sources\n- https://www.php.net/archive/2026.php#2026-10-21-5\n- https://nodejs.org/en/blog/vulnerability/october-2026-security-releases\n- https://pkg.go.dev/vuln/GO-2026-6809\n- https://go.dev/doc/devel/release\n- https://nginx.org/en/security_advisories.html\n- https://github.com/NginxProxyManager/nginx-proxy-manager/releases", "url": "https://gist.github.com/dansku/2132d01a7fc33e91ea57ff36e5c85fd0"}, {"timestamp": "2026-10-23T14:19:34.510Z", "date_only": false, "value": "2026-10-23T14:19:34.510451Z", "kind": "sighting", "label": "Seen", "source": "https://poliverso.org/objects/0477a01e-3e72e79a-c571695ffd7e8052", "record": "CVE-2026-15176", "field": "creation_timestamp", "uuid": "9f4ab24d-40fe-432e-86a8-85e0a7619a08", "content": "This Week in Security: Record Patch Tuesday, PHP\u2019s Bad Time, The Oldest Vuln, AI Armies, and More\nIt\u2019s no longer a proper month without Microsoft breaking its own record for security fixes, and October\u2019s Patch Tuesday was no exception. Brian Krebs brings the roundup: more than 1,400 vulnerabilities fixed in a single batch, dwarfing September\u2019s record of nearly 1,000, which itself was about ten times the normal monthly load. According to Tenable, Microsoft has now passed 4,000 CVEs for the year with two months still to go.\nOnly one of the fixes is for a vulnerability already being exploited in the wild: CVE-2026-96951, a security feature bypass in the Windows Shell affecting Windows 10, 11, and some Server versions. A .NET Framework bypass, CVE-2026-108398, was publicly disclosed before the patch, giving attackers a head start, and with modern AI tooling, it seems like not much of a head start is needed. At least 78 of the bugs are rated critical, and most of those allow remote code execution with little or no user interaction. Windows 10 holdouts can relax a little: Microsoft quietly extended free updates through October 2027.  Given the pace of exploitation, this is probably the only way to prevent an Internet-scale meltdown.\nMicrosoft credits LLM-driven bug hunting for the volume, which leaves the poor admins who have to test and deploy all of this in an unenviable spot. Fortra\u2019s analysis shows that only 26 Microsoft vulnerabilities have landed in the CISA KEV catalog of actively exploited bugs so far this year, so start there. For the rest, the SANS Internet Storm Center and Cisco Talos have the usual breakdowns by severity. Or, you know, just patch everything and hope for the best, which is roughly what everyone does anyhow.\nThe CA private key is\u2026 4\nOriginally I was calling this the \u201cbig one\u201d for the week, but this week that just keeps on giving. The private keys for eight eMudhra intermediate certificates have been compromised, and the way they were compromised is going to be a security talk punchline for years.  Remember the Debian SSL and SSH key debacle?  Of that scale.\nSome background first. When your browser connects to a website over HTTPS, the site presents a certificate saying \u201cI am example.com\u201d, signed by a Certificate Authority (CA). Your browser and OS ship with a list of trusted root CAs, but roots are too valuable to use day to day, so they sign intermediate certificates, and the intermediates sign the actual website certificates. Whoever holds an intermediate\u2019s private key can mint a certificate for any website, and every client that trusts the root will believe it. The whole system depends on those keys staying secret, and on them being generated properly in the first place.\neMudhra, an Indian CA which sells certificates under the emSign brand, had six TLS intermediates and two code-signing intermediates chaining to the emSign ECC Root CA \u2013 G3, which is trusted by Chrome and Apple, and Mozilla. A researcher identified only as Wayne proved the keys were compromised by signing the message \u201cWe have a problem here \u2013 Wayne\u201d with each of them and sending it to the root programs.\nHow did Wayne get the keys? Fl\u00fcpke posted one on Mastodon, and the secret value for the \u201cEM OV TLS CA \u2013 G3C\u201d key is\u2026 4. Not four followed by 380 bits of randomness: the integer four. A reply quickly brute-forced the rest, and they\u2019re all equally tiny: 56, 230, 237, 115, 155, 156, and 66. The keys were \u201cincorrectly generated by the CA\u201d, and anyone could recover them from the public certificates, which has been true since they were created in April 2025.\nThe browsers moved fast. According to The Hacker News, Chrome pushed a block within two hours of the report, and Mozilla blocked the certificates in under three, pulled the root from NSS, and shipped Firefox updates (CVE-2026-113470) for anyone with automatic updates disabled. There are no Certificate Transparency logs of rogue certificates, so modern browsers were never at risk. Everything that isn\u2019t a browser is going to be the real problem and the extremely long tail of this fault: plenty of software never checks for revoked certificates and keeps trusting these keys until its bundled root list is updated.\nGo hard-coded the eight bad keys into its standard library (CVE-2026-111943), but as Penligent points out, that only protects Go programs once they\u2019re rebuilt with the new release. Python, Rust, Java, Node.js, curl, and most Linux distributions have updated root bundles, and the we-have-a-problem.com site has a full list, a checker, and manual workarounds for macOS, whose built-in curl and git don\u2019t check revocation. There are also fixes for Linux, Windows, and the BSDs. Update everything, then go rebuild everything you compiled yourself. And then wonder how you\u2019re going to update appliances, IoT devices, cameras, and everything else that fetches code over HTTPS or SSL.\nphp2shell: PHP gets owned by running out of memory\nPHP, the language behind a significant percentage of the web had a rough week. WordPress, Drupal, Magento, phpMyAdmin, and just about every hosting control panel, major ecommerce sites, home project blogs, and even Hackaday itself was potentially impacted. Details of two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, leaked onto Hacker News a day ahead of the embargo, and Huntress covers the scramble that followed as PHP rushed its release out early. Now that patches are available, Ryan Austin of Calif has published the full writeup, demonstrating pre-authentication remote code execution against important apps on default configurations, in PHP versions back to 5.4.0. That\u2019s over a decade of PHP.\nThe trick is an old one, first found by Stefan Esser back in 2004. PHP enforces a memory limit for each request, and when a request exceeds it, PHP stops immediately with a fatal error. If that happens in the middle of native code updating some internal structure, the structure is left half-built, and the cleanup code that runs afterward trusts it anyhow. That\u2019s a classic \u201cuse-after-free\u201d style bug, where the program uses memory that\u2019s already been released or was never properly set up, and those are frequently exploitable. Calif found ways to reliably push a request over the memory limit at exactly the right moment (deeply nested empty file uploads turn out to balloon into hundreds of megabytes of internal tables, while staying under PHP\u2019s upload size limits), and three different places where the interruption leaves a dangerous mess. Austin found the first bug with a generally available LLM, but only because he knew PHP\u2019s twenty-year history of memory-limit bugs well enough to point it in the right direction.\nAmazon reports that its honeypots caught a php2shell exploitation attempt on October 17th, four days before the embargo lifted, and that it\u2019s now being broadly exploited. Their advice is worth repeating: for critical bugs on internet-facing systems, measure your patch window in hours, not weeks, and start investigating from the earliest exploitation date, not the disclosure date. If you can\u2019t patch right now, Calif suggests disabling session.upload_progress and removing the memory limit, which comes with its own obvious problems.\nOne word of caution: alongside the legitimate writeups, there are many self-published \u201ccorrected findings\u201d and \u201cproof-of-concept\u201d posts that can\u2019t seem to decide whether their own exploit works, while offering a downloadable \u201cweaponized\u201d bundle. A leaked-bug panic is the perfect time to hand anxious admins a zip file. Read the real advisories, and don\u2019t run random proof-of-concept bundles.\nA Sixteen-year-old forever-day in Broadcom WiFi\nQuentin Kaiser has the long-form writeup of his Hexacon talk on a bug in Broadcom\u2019s WiFi stack, present since at least 2010, which gives an attacker a root shell on a router from across the street.  So called \u201cparking lot\u201d attacks that can happen from someone not even on your property have long been the boogeymen of WiFi security, and it\u2019s been a little bit since we\u2019ve gotten a new one.\nThe bug lives in WPS, WiFi Protected Setup: the \u201cpush the button on your router and then on your printer\u201d pairing system that was supposed to save people from typing long WiFi passwords. WPS has a long and spotty security history, and this bug can be triggered over the air without knowing the network password, and without completing a WPS pairing. Kaiser\u2019s demos show him pulling the WiFi password straight out of a router\u2019s settings and sending it back over WiFi, and getting a fully interactive remote shell carried entirely over WiFi frames. No Internet connection required.\nThe really grim part is the patch history. Broadcom quietly released an incomplete fix in 2018, then suggested vendors switch to the open-source hostapd instead. For the older eCos-based chipsets that\u2019s effectively never going to happen, which makes it a permanent \u201cforever-day\u201d. Broadcom refused to assign a CVE, and because Broadcom is its own CVE authority, CERT/CC closed Kaiser\u2019s case the same day it was opened.\nAs of disclosure, the cable and DSL gateways he tested from three of Belgium\u2019s four major ISPs were still vulnerable, and his napkin math puts it at over a million and a half devices in Belgium alone. Broadcom chips are, of course, sold everywhere. If you\u2019re running ISP-provided hardware, there isn\u2019t much you can do about the firmware. Turning off WPS can\u2019t hurt if your router allows it, although Kaiser doesn\u2019t say whether that blocks the attack. Disabling the gateway\u2019s own WiFi and running your own access point that you can actually update is the safer bet.\nGitLab regex bug reaches back twelve years\nGitLab has released fixes for CVE-2026-110264, a maximum-severity CVSS 10.0 bug allowing unauthenticated attackers to run code on self-hosted GitLab servers. The flaw is an integer overflow when compiling a specially crafted regular expression in Onigmo, the Ruby regex engine which GitLab bundles into its own packages, so it affects every version back to GitLab 7.0 in 2014.\nThis is the fourth regex engine code execution bug from the same researcher in about a month (after CVE-2026-97229, CVE-2026-93577, and CVE-2026-89078), and comes with a nasty gotcha: the new fixed versions are one release past the October 12th fix, so if you diligently patched nine days ago, you\u2019re vulnerable again. GitLab hasn\u2019t said what\u2019s needed to trigger the bug, so there\u2019s no configuration workaround. If you\u2019re running GitLab at home or in the shop, patch, and budget for some downtime while the database migrations run.\nNode.js Brotli bug\nNode.js shipped security updates for the 22, 24, and 26 branches, headlined by CVE-2026-111497, an out-of-bounds write in the bundled Brotli decompression library. Vercel\u2019s advisory notes that researchers have demonstrated both memory leaks and command execution.\nNode doesn\u2019t decompress Brotli data on its own, but plenty of applications and libraries do, whether on incoming requests or on responses fetched from other servers. Vercel deployed firewall rules for traffic coming into its own platform, but no firewall can protect your code from a malicious response it goes and fetches itself. Node 20 is end-of-life and won\u2019t be fixed. As a bonus, the same releases carry the eMudhra certificate distrust, so that\u2019s two reasons to go update.\nHeader accordions and HTTP/3\nHTTP/3 is the newest version of the protocol behind the web, running over QUIC (a UDP-based transport) instead of TCP. To save bandwidth, it compresses request headers using a scheme called QPACK: common headers can be sent as a one-byte reference into a table instead of the full text. Compression is great for bandwidth, but any time a small input can turn into a big output, there\u2019s a risk of a \u201cdecompression bomb\u201d.  Similar tricks resulted in \u201czip bombs\u201d in the 2000s, and what\u2019s old is new again.\nFoxIO found exactly that in seven of the ten HTTP/3 implementations they tested. One approach packs about 160,000 unique short headers into a single 1MB request; another stores one 4KB header and then references it thousands of times, a 4000-to-1 amplification. The HTTP/3 spec already says how to limit the decoded size, but implementations got it wrong in every possible way: checking only the compressed size, decompressing everything before checking, ignoring the per-header overhead, or reading the limit setting and then never enforcing it.\nFixed so far are quic-go (CVE-2025-64702), which is used by Caddy, Traefik, and Cloudflare\u2019s tunnels; Cloudflare\u2019s quiche (CVE-2026-12523); lsquic 4.9.0; and even Wireshark (CVE-2025-13945), whose QPACK decoder crashed during testing. Bun, the hyperium h3 Rust crate, and aioquic/mitmproxy remain unpatched. Bun gets special mention for an integer overflow that turns a single 516KB request into a permanent 100% CPU infinite loop. The lesson applies to any compression format: limit the decompressed size as you go, not just the bytes on the wire.\nMetamorphic macOS ransomware\nPatrick Wardle of Objective-See digs into Heartbreaker, macOS ransomware written in Rust that has sat on VirusTotal since May 2025, undetected by every antivirus engine.\nMost antivirus detection relies on signatures: a hash or byte pattern identifying a known-bad file. Metamorphic malware tries to dodge signatures by rewriting itself so every copy looks different while behaving the same. Heartbreaker takes a delightfully brute-force approach: it carries its own Rust source code inside the binary, and after running, it shuffles variable names, adds junk functions, installs a Rust compiler if one isn\u2019t present, recompiles itself, and replaces itself with the new build. It is about as subtle as a brick through a window.\nAs ransomware it\u2019s not very scary. It only encrypts the Downloads folder, and uses the same hard-coded key for every victim, so Wardle simply wrote a decryptor. The rebuilding also depends on a GitHub library which has since disappeared, so it mostly fails anyhow. Wardle uses it to demonstrate his free RansomWhere? tool, which ignores signatures completely and instead watches for an untrusted process rapidly writing files that look encrypted (using a bit of entropy math). The malware can change its hash all day long, but to ransom anything it still has to encrypt the files, and that\u2019s much harder to disguise.\nUpdraftPlus vendor breached\nTeamUpdraft, the company behind the very popular UpdraftPlus WordPress backup plugin, disclosed a breach of their customer database over the weekend. Names, emails, addresses, hashed passwords, and two-factor authentication settings were taken, and more worryingly, the connection keys for UpdraftCentral, their cloud dashboard for managing many WordPress sites at once. UpdraftPlus previously made an appearance back in June, when a vulnerability in the plugin was used in the Awesome Motive supply chain attack.\nThose UpdraftCentral keys can send commands to every connected site, which turns one vendor breach into a remote control for potentially thousands of customer websites. TeamUpdraft has released UpdraftPlus 1.26.12 and 2.26.12, which automatically disconnect the old keys. If you or anyone you know manages WordPress sites through UpdraftCentral, log in to each site directly, update the plugin, and check for unexpected admin accounts and plugins (including the easy-to-miss \u201cMust-Use\u201d plugins tab).\nSpyware delivered by ad network\nCitizen Lab has published research showing that the Israeli ad-tech company Discover-Tech helped deliver spyware through ordinary online ads, targeting at least 45 devices at the news outlet Al Jazeera in 2024 and 2025. Citizen Lab attributes the spyware to Candiru, a commercial spyware vendor.\nWhen you load a web page with ads, the ad slot is typically auctioned off in real time to the highest bidder, based on a profile of who you seem to be. This \u201cprogrammatic advertising\u201d system is, by design, a mechanism for running third-party content on a very specific person\u2019s device. It\u2019s easy to see why that\u2019s attractive to a spyware vendor. According to Citizen Lab, Discover-Tech\u2019s platform could profile users and infect a device just by displaying an ad, no click required. CPJ reports that the company\u2019s ads reached nearly 200,000 websites and apps, and researchers at Confiant found them on government networks including the US Department of Defense, NATO, and the UN.\nMalicious ads are nothing new, but this is the first public evidence of an ad platform being used for targeted, zero-click spyware delivery. \u201cDon\u2019t click on ads\u201d has always been good advice. An ad blocker isn\u2019t just a quality-of-life improvement; it\u2019s attack surface reduction.\nRansomware negotiators on the wrong side\nLast week we covered a ransomware \u201crecovery\u201d CEO charged with secretly paying ransoms while billing customers for decryption. This week, Brian Krebs reports that investigators chasing ShinyHunters (the group behind the FBI hack) have identified executives at two ransomware negotiation firms with unusually friendly relationships with the gang. Chats seized when Dutch police arrested a suspected ShinyHunters member reportedly show negotiators who knew about new victims before the victims themselves did. One Canadian executive has already been arrested, and investigators believe an executive at an unnamed, prestigious US consulting firm helped run the gang\u2019s extortion website.\nIt\u2019s not the first time: the DOJ sentenced Florida negotiator Angelo Martino to 70 months in July for feeding his own clients\u2019 negotiating positions to the BlackCat ransomware gang, and for helping deploy ransomware against even more victims. The government seized $10 million in assets from him, including a luxury fishing boat and, for reasons unknown, a food truck.\nPart of the problem is structural. Some negotiation firms charge a percentage of the ransom paid, which gives the \u201cnegotiator\u201d every incentive to pay, and pay big. Firms which refuse to facilitate payments often just get swapped out by the insurance company for ones that will. Meanwhile, ShinyHunters is reportedly furious with Coveware, an incident response firm, for telling victims not to pay, which is probably the best endorsement Coveware could ask for.\nAn army of AI agents\nThe Verge reports that security firm Norforge found an attacker using a swarm of mostly autonomous AI agents to break into more than 100 websites, including sites belonging to John Deere, SharkNinja, and Cummins. The agents ran on Cairn, an open-source \u201cgeneral-purpose problem-solving engine\u201d: you give it a starting point and a goal, and the agents work toward it while documenting their progress. That documentation is how they were caught: the attacker\u2019s Cairn instance was exposed to the Internet, along with about 20 others that appear malicious.\nAccording to Reuters, the attacker described their preferred intrusion tactics in fewer than 100 Chinese characters, and each successful breach took about 23 hours. The victims say the impacted sites were standalone support pages, and Cairn\u2019s author insists it was \u201cnever a \u2018hacking tool'\u201d. Many tools can be double-edged, but the effort balance here is hard to ignore: a short prompt and a day of waiting on one side, and defenders who have to close every hole on the other.\nStaples hacked to fund a gift cards\n404 Media pieced together, from an unsealed search warrant, that a Chinese organized crime ring hacked Staples in 2023 and issued more than 15,000 gift cards worth over $5 million. Staples\u2019 internal customer support system was supposed to be reachable only from inside the company, but wasn\u2019t. The attackers requested \u201cheap dumps\u201d, a debugging feature which captures everything an application has in memory, and pulled out the active login sessions of customer service reps. With those, they simply logged in as the reps and issued gift cards.  A similar trick was used in a hack of payment data from Target years ago, where attackers leveraged access through the air conditioner control network into the cash register network, and then dumped credit cards directly from RAM as they were processed.\nIf you\u2019ve ever wondered why debugging endpoints left exposed in production show up in every penetration test report, this is why. The gift cards were then laundered the old-fashioned way: crews of shoppers hitting Target stores with phones full of gift cards, buying Apple and Bose gear by the cartload (about $141,000 across 85 Target stores in 18 states in two days), with the goods shipped back to China. The larger ring this fed into reportedly moved over $100 million in gift cards.\nPingCAP breach claims\nAn extortion group calling itself FulcrumSec has posted a leak site claiming a massive breach of PingCAP, makers of the TiDB Cloud managed database service. The group claims it found cloud credentials committed to PingCAP\u2019s own source code repositories, and used them to set up a replication feed of PingCAP\u2019s production control database that re-exported everything to the attackers every six hours for 22 days, without being noticed.\nThe claims haven\u2019t been independently verified, but they\u2019re very specific: 10.6TB of data, 115,000 customer API keys stored in plaintext, 20 million customer SQL queries, four years of connection logs with customer IP addresses, and 413 private source repositories. The attackers quote a 2022 internal security ticket noting that any member of a customer organization, even a billing-only account, could reset the root password on every database in that organization. Perhaps most damaging, support engineers allegedly pasted live customer credentials into support tickets, including cloud keys with admin access to other companies\u2019 storage. If you\u2019re a TiDB Cloud customer, assume your API keys, connection strings, and anything ever pasted into a support ticket are burned, and rotate accordingly.\nFake WhatsApp on the Play Store\nAndroid Authority found a fake WhatsApp app on Google Play with over half a million downloads, a week after a fake Chrome app racked up over 100,000. The fake copied the real listing\u2019s screenshots and description word for word, and in some cases appeared as a sponsored result when searching for the real app.\nThe trick that let it linger is Google Play\u2019s \u201cEarly Access\u201d program, which disables public reviews. Normally a fake app gets buried in one-star \u201cTHIS IS A SCAM\u201d reviews; in Early Access, nobody can see them. As of publication it was still available. \u201cOnly install from the official store\u201d is still good advice for family members, but it\u2019s a little less reassuring when the official store is selling ad placement to the fake.\nMeta Muse leaks via DNS\nBack in September, we covered a serious vulnerability in Muse, Meta\u2019s extremely privileged AI agent. This week, Meta suspended Muse\u2019s chat sharing feature after researchers at Claroc found they could find and read thousands of shared conversations.\nEach shared chat got its own web address, with the conversation title as part of the hostname. Hostnames get looked up in DNS, and many DNS lookups are recorded by \u201cpassive DNS\u201d services, essentially a giant searchable history of which names have been resolved. One search returned a ready-made table of contents of shared chats. Claroc found 6,800 of them, including a small business loan application, a bank fraud alert with partial account details, and internal company documents. \u201cSecret URL\u201d sharing only works if the URL stays secret, and putting the secret in a DNS hostname is roughly the opposite of that.\nPassword1 strikes again\nThe UK Information Commissioner\u2019s Office reprimanded IT provider Ogi Networks and the Welsh public sector data organization Data Cymru over a 2024 ransomware attack which exposed data on 3,300 people, most of them children. The way in? A test account named \u201cTest2\u201d, created in 2012, never reviewed, and protected with the password \u201cPassword1\u201d. The local administrator accounts on three systems also shared a single password for the same twelve years.\nThere\u2019s nothing exotic here, sadly. Old accounts nobody remembers, passwords that would fall to the first guess of any automated tool, and an outsourcing arrangement where each side assumed the other was handling security. None of it makes for exciting headlines, but these are the things that keep causing very real breaches.\nTrezor wallets also implanted\nAs a follow-up to last week\u2019s coverage of hardware implants in Ledger crypto wallets, Kim Zetter reports that Trezor\u2019s claim of \u201cnot a single piece of evidence\u201d that its devices were compromised doesn\u2019t quite line up with reality. Joe Grand found implants in two Trezor wallets, bought through Facebook Marketplace and a TikTok shop, and reported them to Trezor in August.\nThe Trezor attack is different from the Ledger implant. Instead of adding a radio to spy on the screen, the attackers replaced the main microcontroller with one running modified (open source) firmware. The firmware \u201crandomly\u201d generates one of a dozen recovery phrases the attackers already know. To pass Trezor\u2019s integrity checks, it presents a copy of the legitimate firmware for verification before switching to the malicious code. The takeaway hasn\u2019t changed from last week: buy only directly from the vendor, and if you\u2019re holding enough crypto to make this worth someone\u2019s while, consider whether you can really trust any single device.\nNGINX gets more critical bugs\nF5 has released out-of-band (meaning outside their normal patch schedule) updates for three critical vulnerabilities in NGINX, the web server and reverse proxy that sits in front of a huge chunk of the Internet, and quite possibly in front of the services on your home lab. The Cyber Security Agency of Singapore has a summary: all three are rated CVSS 9.2, can be triggered remotely without authentication, and can crash worker processes or, under the right conditions, allow remote code execution.\nThe bugs are CVE-2026-15176, a heap overflow in the \u201calias\u201d and \u201crewrite\u201d directives; CVE-2026-97205, a use-after-free in asynchronous file I/O combined with Server Side Includes; and CVE-2026-93479, a heap overflow in the \u201cmap\u201d directive. Code execution requires the vulnerable configuration to be in use, and requires bypassing ASLR (the randomization of memory layout which makes exploits harder to aim). Affected versions include NGINX Open Source 1.30.5 and below and 1.31.6 and below, NGINX Plus R33 through R37, and a long list of F5\u2019s NGINX-based products, including the Kubernetes Ingress Controller.\nBack in May we covered \u201cnginx-poolslip\u201d, where the suggested mitigation was to avoid unnamed regex capture groups in rewrite rules. The mitigation for the \u201cmap\u201d bug this time? Use named captures instead of unnamed captures. If you\u2019ve been putting off cleaning up those \u201c$1\u201d references in your config, now\u2019s the time. For the other two, avoid \u201calias\u201d inside \u201clocation\u201d blocks (and the \u201c$request_filename\u201d variable), or disable AIO or SSI, until you can update.\nLinux kernel bugs posted to the wrong list\nNormally, security bugs in the Linux kernel are reported privately to the kernel security team, which coordinates a fix before details go public. This is \u201ccoordinated disclosure\u201d: the bug and fix are published together, ideally giving admins a chance to patch before attackers can start writing exploits. The Linux Kernel Mailing List (LKML), on the other hand, is about as public as it gets.\nPhoronix reports that Trend Micro\u2019s Zero Day Initiative, seemingly by accident, sent a batch of unpatched vulnerability reports straight to LKML. Greg Kroah-Hartman replied to each report asking about the choice of mailing list, which I can only imagine was done with remarkable restraint. The most serious two are both CVSS 9.0 remote code execution bugs in ksmbd, the kernel\u2019s built-in SMB (Windows file sharing) server: an integer underflow in SMB Direct, and a race condition. The rest include local privilege escalation bugs in the networking code, the VMware graphics driver (an out-of-bounds write), and a stack overflow in search-domain TCP query handling, plus an information leak in the NVMe-over-fabrics target code.\nSome of the bugs already have patches being tested or queued for future kernel releases, and those will presumably be expedited now. Most systems don\u2019t run ksmbd (the userspace Samba server is far more common), but if you\u2019ve enabled it on a NAS or a home server, it\u2019s worth disabling until patched kernels land. As Phoronix puts it: \u201cthe bug and security reports keep on coming in the AI fueled world.\u201d \nhackaday.com/2026/10/23/this-w\u2026RE: chaos.social/users/fluepke/sta\u2026", "url": "https://poliverso.org/objects/0477a01e-3e72e79a-c571695ffd7e8052"}]}