An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. django.contrib.admin.utils.displayforfield() renders URLField values as clickable links in the admin without validating the URL. A value stored with an unsafe scheme is displayed as a link on changelist and read-only admin pages, which allows cross-site scripting against staff users who click the link. Exploitation requires the unsafe value to already be stored in the database. URLField validation through a ModelForm or the admin rejects unsafe schemes, so this affects applications that persist URLField data without running model validation, for example through direct queryset writes, deserialization, or bulk import of untrusted input. Django would like to thank Egor Saltykov for reporting this issue.
Apache Thrift: Python TSSLSocket Hostname Matcher Import
Apache Thrift: cglib heap out-of-bounds read in transport leftover-bytes path
Apache Thrift: C++ heap out-of-bounds read in THeaderTransport::readHeaderFormat()
Allocation of Resources Without Limits or Throttling vulnerability in Apache Thrift Java bindings.
This issue affects Apache Thrift: from 0.19.0 before 0.24.0.
Users are recommended to upgrade to version 0.24.0, which fixes the issue.
BIND may accept incorrect child-zone NSEC3 records as valid, allowing forged authenticated NXDOMAIN responses for sibling zones. AC:H (high complexity) keeps severity at Medium despite S:C.
A flaw was found in rpcbind's rpcinfo utility. In rpcbdump() short mode, used by rpcinfo -s, version values returned by a remote RPCBPROCDUMP reply are appended via unbounded sprintf() calls into a fixed 256-byte stack buffer without tracking remaining space:
c char buf[256]; char p = buf; for (vl = rs->vlist; vl; vl = vl->next) { sprintf (p, "%d", vl->vers); p = p + strlen (p); if (vl->next) sprintf (p++, ","); }
A malicious or compromised rpcbind endpoint that returns enough distinct version numbers for a single program (roughly 24 maximum-width decimal values plus separators) can overflow this buffer. A user or administrator must run rpcinfo -s <host> against the hostile endpoint; no privileges on the victim are required, but user interaction is needed. Current evidence supports client-side stack memory corruption leading to a crash/denial of service of the rpcinfo client process; disclosure or reliable code execution are not established.
This bug was originally reported bundled together with a related, since-fixed overflow in rpcbaddrlist() (now tracked separately as CVE-2026-16277). Confirmed via direct inspection of upstream commit bb9bb7286a4c345442946dc2ce3c9e7f67e96d4d (rpcbind 1.2.9) that this rpcbdump() short-mode overflow is NOT fixed by that commit and remains present in the latest upstream release.
Steps to reproduce: 1. Build rpcbind with AddressSanitizer: CFLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer" ./configure && make -j 2. Run a malicious rpcbind-compatible endpoint, or an instrumented test responder. 3. Return an RPCBPROCDUMP list for one program with enough distinct versions (~24+ max-width decimal values) to exceed 256 bytes. 4. Run ./src/rpcinfo -s <attacker-host>. 5. Observe an ASan stack-buffer-overflow report or client crash.
Proposed fix (not yet applied upstream): convert the version-list formatter to bounded snprintf() calls that track remaining buffer space. diff char p = buf; +char p = buf; +sizet rem = sizeof(buf); +int n; +buf[0] = '\0'; for (vl = rs->vlist; vl; vl = vl->next) { - sprintf (p, "%d", vl->vers); - p = p + strlen (p); - if (vl->next) - sprintf (p++, ","); + n = snprintf(p, rem, "%d%s", vl->vers, vl->next ? "," : ""); + if (n < 0) + break; + if ((sizet)n >= rem) { + p = buf + sizeof(buf) - 1; + break; + } + p += n; + rem -= (sizet)n; }
A stack-based buffer overflow was found in rpcbind's rpcinfo utility. When querying a remote rpcbind service with rpcinfo -l, address information returned by the server is copied into a fixed-size buffer without sufficient bounds checking. A malicious or compromised rpcbind server could use this flaw to crash the rpcinfo client, resulting in a denial of service. The highest threat from this vulnerability is to system availability.