<div dir="ltr">Thanks for the quick fix, and for the correction about the list. I had that backwards: I treated it as the private option because there was no security contact, when it has public archives and the bug tracker would have been the less exposed route. I will use the tracker for Xapian in future.<br><br>On the severity block, I will drop it. Plain version: this only bites a caller who passes empty hi_start and hi_end and then renders the snippet as HTML, and your codesearch is good evidence that essentially nobody does the first part. So the real-world exposure is low and I would not argue for treating it as more than a correctness fix.<br><br>Thanks again,<br>Arpit<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2026 at 8:51 AM Olly Betts <<a href="mailto:olly@survex.com">olly@survex.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Aug 11, 2026 at 07:47:04PM +0900, Arpit Jain wrote:<br>
> Since Xapian publishes no private security contact, I am writing to the<br>
> list rather than putting this anywhere more public; my name is Arpit Jain<br>
> and I work on open-source supply-chain security.<br>
<br>
FWIW, this list has multiple external public archives.  Probably our bug<br>
tracker is actually less public than this list.<br>
<br>
> I think Xapian::MSet::snippet() in xapian-core breaks its documented<br>
> HTML-escaping guarantee on one fast path: when hi_start and hi_end are both<br>
> empty and the text already fits inside length, it returns the caller's text<br>
> byte for byte with no escaping.<br>
<br>
Indeed - thanks for reporting.  As you identified, it's effectively a<br>
missed case from CVE-2018-0499.<br>
<br>
I've pushed fixes to main and RELEASE/1.4.  I'm already working on new<br>
releases so this should hopefully be in releases soon.<br>
<br>
> Severity and classification (my read, your call)<br>
> ------------------------------------------------<br>
> Medium. CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N. CWE-116, with CWE-79<br>
> as the downstream effect. AC is High because the impact depends on a caller<br>
> configuration the attacker does not control, and scope is Changed because<br>
> the consequence lands in the embedding application's browser context rather<br>
> than in Xapian.<br>
<br>
Sorry, I don't know what any of that means!<br>
<br>
I'd expect that it's uncommon to pass empty hi_start and hi_end,<br>
especially when used in a web context (since end users will expect<br>
search terms to be highlighted in snippets because that's (a) helpful<br>
and (b) what pretty much every search system does).<br>
<br>
I used Debian codesearch to find code in software packaged by Debian<br>
which uses MSet::snippet() (unfortunately there are a lot of unrelated<br>
matches as well):<br>
<br>
<a href="https://codesearch.debian.net/search?q=(%5C.%7C-%3E)%5Cb*snippet%5Cb*%5C(%5B%5E')0-9%5D&literal=0" rel="noreferrer" target="_blank">https://codesearch.debian.net/search?q=(%5C.%7C-%3E)%5Cb*snippet%5Cb*%5C(%5B%5E')0-9%5D&literal=0</a><br>
<br>
All the calls I found use non-empty hi_start and hi_end.  That's likely<br>
a subset of users of this API but at least indicative.<br>
<br>
Cheers,<br>
    Olly<br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><span style="font-size:12.8px">Thanks,</span></div><div><span style="font-size:12.8px">Arpit </span></div></div></div></div></div></div>