Bug#1144490: libxapian30: previously missed corner case of CVE-2018-0499

Hi Olly,

On Sun, Aug 16, 2026 at 09:57:33AM +1200, Olly Betts wrote:
> 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.

FTR, I requested a CVE for this issue so we can properly track it as
separate CVE id.

Regards,
Salvatore