Ancient Bugs, Forged IDs, and the AI Model Taking On PostgreSQL's Query Planner

A 32-year-old memory corruption bug discovered in the GNU inetutils Telnet server — CVE-2026-32746 — drew 68 points and 28 comments. WatchTowr Labs was not auditing Telnet specifically; the server surfaced during a broader review of network daemons, a reminder that Telnet persists in industrial control systems, legacy network equipment, and embedded devices where 'we'll replace it eventually' became 'we replaced everything around it but not this.' The bug involves a memory corruption issue in how the server handles option negotiation during the Telnet handshake, and predates modern memory safety conventions by a wide margin.

A related finding about US driver's license barcodes received 192 points and 70 comments. A researcher's post titled 'Keys Not Included' describes recovering the signing keys used in the PDF417 barcodes on the back of state-issued licenses. The finding is that many states implemented the AAMVA standard in ways that made signing keys recoverable — through weak key derivation, keys shared across large populations of licenses, or in some cases keys derivable from information printed on the card itself. A recoverable signing key means a barcode can be crafted that passes verification, which is relevant for age-verification and identity-check systems that rely on barcode scanning. The researcher disclosed responsibly and worked with affected states before publishing; the structural problem — that the AAMVA standard is voluntary, implementation is handled by individual state DMVs with varying technical sophistication, and no central authority conducts security audits — is not resolved by individual disclosure.

The database story attracting the most attention — 567 points, 120 comments, third-highest of the day — involves a researcher who trained a 4-billion parameter model specifically to produce SQL query execution plans and benchmarked it against PostgreSQL's native planner, reporting an 81% improvement on the TPC-H benchmark suite. PostgreSQL's query planner, built over three decades, selects indexes, join order, join algorithms, and filter sequencing to determine whether a query takes 10 milliseconds or 10 seconds; the researcher's argument is that a learned model can internalize those patterns more accurately than hand-crafted statistical heuristics.

Community scrutiny was appropriately rigorous. TPC-H is a standardized analytical benchmark with well-understood statistical properties, and PostgreSQL's planner has known weaknesses on that benchmark that the database community has debated for years. A model trained specifically on TPC-H-like queries performing well on TPC-H says limited about generalization to arbitrary workloads, schema changes, skewed data distributions, or the irregular queries that production databases routinely encounter. Skeptics noted that PostgreSQL's planner also optimizes for planning speed, predictability, and resilience on tail cases — a plan that is 20% slower on average but never catastrophically fails is often preferable to one that is 81% faster on average but occasionally produces a 100-second query. The signal worth watching: whether the research spawns a PostgreSQL extension reporting performance numbers on real production workloads.

A quieter post comparing memory allocators — arena-based allocators, glibc ptmalloc, jemalloc, and mimalloc — across fragmentation, allocation latency, thread contention, and memory overhead drew 81 points and 14 comments. The practical takeaway for systems programmers: the optimal allocator depends heavily on allocation pattern, with high-churn short-lived allocations favoring arena allocators and mixed lifetimes with frequent frees benefiting more from implementations such as mimalloc.