Package: libxapian30 Version: 1.4.31-2 Fixed: 1.4.32-1 Severity: serious Tags: security Justification: potential security vulnerability X-Debbugs-Cc: Debian Security Team <[email protected]>
This was reported to upstream's public development list: https://lists.xapian.org/pipermail/xapian-devel/2026-August/003429.html The bug is missing HTML escaping, potentially allowing an attacker to inject unescaped data into generated HTML search results. It's effectively a corner case missed when we fixed CVE-2018-0499. It affects upstream releases 1.4.x for x <= 31 and 2.0.0. Upstream releases 1.4.32 and 2.0.1 include a fix, and I've already uploaded 1.4.32 to unstable and 2.0.1 to experimental. There are patches here: https://trac.xapian.org/wiki/SecurityFixes/2018-07-02#a2026-08-13update The actually fix is just this (the patches also add test coverage): if (hi_start.empty() && hi_end.empty() && text.size() <= length) { - // Too easy! - return text; + // The text is already short enough so we just need to perform + // escaping. + string output; + append_escaping_xml(text.data(), text.data() + text.size(), output); + return output; } The 4 variables in the condition are all parameters from the MSet::snippet() API call. In order to be exploited, hi_start and hi_end need to be passed as empty strings (they have default values which aren't empty). I'd expect most usage in a web context would want to highlight matching terms in the snippet and so it's probably uncommon to pass empty string here - I looked for an example of such usage with codesearch.d.n but didn't find anything. However empty highlighting strings are a legitimate way to call this method, and I may have missed an instance, or such use may be present in code that hasn't been packaged for Debian. Therefore I think we should apply this patch to stable. I've already contacted the security team and they said we should handle this via a stable update. Cheers, Olly
