{"api_version":"1","generated_at":"2026-09-11T02:52:19+00:00","cve":"CVE-2026-89092","urls":{"html":"https://cve.report/CVE-2026-89092","api":"https://cve.report/api/cve/CVE-2026-89092.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-89092","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-89092"},"summary":{"title":"Stack overflow in nscd due to unbounded alloca use","description":"The nscd service in the GNU C Library 2.3.4 onwards may crash due to a \nstack overflow when a malicious DNS server returns too large a response \nfor a DNS query, resulting in degraded DNS resolution for the system.\n\n\n\nExploitation of this bug needs a system that has nscd enabled and using \nan untrusted DNS server for name resolution, with the compromised DNS \nserver being capable of processing records large enough to result in a \nstack overflow in an nscd thread stack.  During experimentation, bind 9 \nwas unable to handle large records, but that could change in future or \nwith a different name server.  In typical installations, nscd is \nexecuted in an isolated context as its own user without a shell, due to \nwhich any compromise of that service is isolated.\n\n\n\nThere is a remote possibility of nscd cache corruption if an attacker \nmanages to get the stack pointer into a desired point in the heap, \npotentially resulting in other caches in nscd being overwritten with \ncorrupt data through the stack overflow, until the buggy code path \neventually results in a crash.\n\n\n\nFinally, a crash in nscd may result in performance degradation when \nresolving names, but it does not result in a denial of service.","state":"PUBLISHED","assigner":"glibc","published_at":"2026-09-11 02:18:35","updated_at":"2026-09-11 02:18:35"},"problem_types":["CWE-789","CWE-789 CWE-789 Memory allocation with excessive size value"],"metrics":[{"version":"3.1","source":"3ff69d7a-14f2-4f67-a097-88dee7810d18","type":"Secondary","score":"4.2","severity":"MEDIUM","vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L","baseScore":4.2,"baseSeverity":"MEDIUM","attackVector":"ADJACENT_NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"LOW","availabilityImpact":"LOW"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"4.2","severity":"MEDIUM","vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L","data":{"attackComplexity":"HIGH","attackVector":"ADJACENT_NETWORK","availabilityImpact":"LOW","baseScore":4.2,"baseSeverity":"MEDIUM","confidentialityImpact":"NONE","integrityImpact":"LOW","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L","version":"3.1"}}],"references":[{"url":"https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0016","name":"https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0016","refsource":"3ff69d7a-14f2-4f67-a097-88dee7810d18","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://sourceware.org/bugzilla/show_bug.cgi?id=34624","name":"https://sourceware.org/bugzilla/show_bug.cgi?id=34624","refsource":"3ff69d7a-14f2-4f67-a097-88dee7810d18","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89092","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89092","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"The GNU C Library","product":"glibc","version":"affected 2.3.4 2.45 custom","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Anmol Singh Rajput","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"glibc","vendor":"The GNU C Library","versions":[{"lessThan":"2.45","status":"affected","version":"2.3.4","versionType":"custom"}]}],"credits":[{"lang":"en","type":"finder","value":"Anmol Singh Rajput"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"The nscd service in the GNU C Library 2.3.4 onwards may crash due to a \nstack overflow when a malicious DNS server returns too large a response \nfor a DNS query, resulting in degraded DNS resolution for the system.\n<br>\n<br>Exploitation of this bug needs a system that has nscd enabled and using \nan untrusted DNS server for name resolution, with the compromised DNS \nserver being capable of processing records large enough to result in a \nstack overflow in an nscd thread stack.&nbsp; During experimentation, bind 9 \nwas unable to handle large records, but that could change in future or \nwith a different name server.&nbsp; In typical installations, nscd is \nexecuted in an isolated context as its own user without a shell, due to \nwhich any compromise of that service is isolated.\n<br>\n<br>There is a remote possibility of nscd cache corruption if an attacker \nmanages to get the stack pointer into a desired point in the heap, \npotentially resulting in other caches in nscd being overwritten with \ncorrupt data through the stack overflow, until the buggy code path \neventually results in a crash.\n<br>\n<br>Finally, a crash in nscd may result in performance degradation when \nresolving names, but it does not result in a denial of service.&nbsp;"}],"value":"The nscd service in the GNU C Library 2.3.4 onwards may crash due to a \nstack overflow when a malicious DNS server returns too large a response \nfor a DNS query, resulting in degraded DNS resolution for the system.\n\n\n\nExploitation of this bug needs a system that has nscd enabled and using \nan untrusted DNS server for name resolution, with the compromised DNS \nserver being capable of processing records large enough to result in a \nstack overflow in an nscd thread stack.  During experimentation, bind 9 \nwas unable to handle large records, but that could change in future or \nwith a different name server.  In typical installations, nscd is \nexecuted in an isolated context as its own user without a shell, due to \nwhich any compromise of that service is isolated.\n\n\n\nThere is a remote possibility of nscd cache corruption if an attacker \nmanages to get the stack pointer into a desired point in the heap, \npotentially resulting in other caches in nscd being overwritten with \ncorrupt data through the stack overflow, until the buggy code path \neventually results in a crash.\n\n\n\nFinally, a crash in nscd may result in performance degradation when \nresolving names, but it does not result in a denial of service."}],"impacts":[{"capecId":"CAPEC-142","descriptions":[{"lang":"en","value":"CAPEC-142 DNS Cache Poisoning"}]}],"metrics":[{"cvssV3_1":{"attackComplexity":"HIGH","attackVector":"ADJACENT_NETWORK","availabilityImpact":"LOW","baseScore":4.2,"baseSeverity":"MEDIUM","confidentialityImpact":"NONE","integrityImpact":"LOW","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L","version":"3.1"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-789","description":"CWE-789 Memory allocation with excessive size value","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-09-11T01:23:01.162Z","orgId":"3ff69d7a-14f2-4f67-a097-88dee7810d18","shortName":"glibc"},"references":[{"tags":["issue-tracking"],"url":"https://sourceware.org/bugzilla/show_bug.cgi?id=34624"},{"tags":["vendor-advisory"],"url":"https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0016"}],"source":{"discovery":"UNKNOWN"},"title":"Stack overflow in nscd due to unbounded alloca use","x_generator":{"engine":"Vulnogram 1.0.5"}}},"cveMetadata":{"assignerOrgId":"3ff69d7a-14f2-4f67-a097-88dee7810d18","assignerShortName":"glibc","cveId":"CVE-2026-89092","datePublished":"2026-09-11T01:23:01.162Z","dateReserved":"2026-09-10T20:18:09.584Z","dateUpdated":"2026-09-11T01:23:01.162Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-11 02:18:35","lastModifiedDate":"2026-09-11 02:18:35","problem_types":["CWE-789","CWE-789 CWE-789 Memory allocation with excessive size value"],"metrics":{"cvssMetricV31":[{"source":"3ff69d7a-14f2-4f67-a097-88dee7810d18","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L","baseScore":4.2,"baseSeverity":"MEDIUM","attackVector":"ADJACENT_NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"LOW","availabilityImpact":"LOW"},"exploitabilityScore":1.6,"impactScore":2.5}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"89092","Ordinal":"1","Title":"Stack overflow in nscd due to unbounded alloca use","CVE":"CVE-2026-89092","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"89092","Ordinal":"1","NoteData":"The nscd service in the GNU C Library 2.3.4 onwards may crash due to a \nstack overflow when a malicious DNS server returns too large a response \nfor a DNS query, resulting in degraded DNS resolution for the system.\n\n\n\nExploitation of this bug needs a system that has nscd enabled and using \nan untrusted DNS server for name resolution, with the compromised DNS \nserver being capable of processing records large enough to result in a \nstack overflow in an nscd thread stack.  During experimentation, bind 9 \nwas unable to handle large records, but that could change in future or \nwith a different name server.  In typical installations, nscd is \nexecuted in an isolated context as its own user without a shell, due to \nwhich any compromise of that service is isolated.\n\n\n\nThere is a remote possibility of nscd cache corruption if an attacker \nmanages to get the stack pointer into a desired point in the heap, \npotentially resulting in other caches in nscd being overwritten with \ncorrupt data through the stack overflow, until the buggy code path \neventually results in a crash.\n\n\n\nFinally, a crash in nscd may result in performance degradation when \nresolving names, but it does not result in a denial of service.","Type":"Description","Title":"Stack overflow in nscd due to unbounded alloca use"}]}}}