I apologize in advance for not having a lot of information about this.. but while I was doing an image search and visiting one of the listed images, I noticed that my browser was trying to render the bytes of an image/png into the target frame instead of attempting to decode as an image file.
As I wasn't expecting this (and had closed the tab containing the state of the query some time ago), the only information I have in regards to reproduceability is literally the https://kagi.com/proxy/... url and the HTTP headers that I receive for the exact request. Hence, this might be considered a search-quality issue from when the image was indexed.
Essentially the query that I remember doing was: https://kagi.com/images?q=robert+crumb
This resulted in the following url: https://kagi.com/proxy/6a01a3fcec1396970b0240a4f8bf85200d-600wi?c=-nDJlTZu1dItIUvn09zADk3WN22uRSasbhLoBrOnZHabSTshkS1QA5wzra7huApZ6MY63cMG-VYdBhsud84F25vPAP-kO6pI3isniBSv_lmrcLI7XcLOxTUQDAxcbIha
The headers for my request are the following (with the "kagi_session" key excluded from the cookie header).
GET /proxy/6a01a3fcec1396970b0240a4f8bf85200d-600wi?c=-nDJlTZu1dItIUvn09zADk3WN22uRSasbhLoBrOnZHabSTshkS1QA5wzra7huApZ6MY63cMG-VYdBhsud84F25vPAP-kO6pI3isniBSv_lmrcLI7XcLOxTUQDAxcbIha HTTP/2
Host: kagi.com
User-Agent: Mozilla/5.0 (Windows NT 5.0; U; en-US) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 UBrowser/7.0.69.1022 w3m/0.5.3 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://kagi.com/images?q=robert+crumb
DNT: 1
Connection: keep-alive
Cookie: _kagi_search_=x4Jeecog4W6oPDSjxf7aDuEoTZsN7374Sl1KrGsMOs6mduY%2Fl%2F%2FWeuBn%2F94H9Z7dwXHM3aJ3fIAvWZ6UHapQZEEAmdYW0hVV0zwDkbkPeOA%3D--0Jceux0paQMyY95n2NdqivPpc8I%3D
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
The response is the following (again with the "kagi_session" key being excluded from the set-cookie header).
HTTP/2 200
x-request-id: 6e538a1f-5c9c-4750-a8e0-e998afb71f28
date: Sun, 21 Jan 2024 10:56:58 GMT
x-frame-options: SAMEORIGIN
content-security-policy: default-src 'none';base-uri 'none';connect-src 'self' https://speedtoost.pixelinc.workers.dev https://speedtest.kagi.workers.dev https://kagi.com https://*.kagi.com/ https://*.mapbox.com/ https://*.hereapi.com/ https://en.wikipedia.org/* https://*.apple-mapkit.com/ https://gsp10-ssl.ls.apple.com https://static.midomi.com https://*.googleapis.com https://*.gstatic.com;font-src 'self' https://*.kagi.com/ https://kagi.com data:; form-action 'self' https:;frame-src 'self' https://*.kagi.com/ https://www.sandbox.paypal.com/ https://www.paypal.com/; frame-ancestors 'none';img-src 'self' localhost:* https://*.apple-mapkit.com/ https://*.kagi.com/ http://static.soundhound.com https://upload.wikimedia.org https://kagifeedback.org https://*.gstatic.com https://*.googleapis.com https://www.paypalobjects.com/ http://www.wolframcdn.com/* data: blob:; media-src 'self' https://kagifeedback.org https://*.kagi.com/; style-src 'self' https://*.kagi.com/ https://static.midomi.com 'unsafe-inline'; worker-src 'self' https://*.kagi.com/ blob:;child-src 'self' https://*.kagi.com/ blob:;object-src 'none';
referrer-policy: same-origin
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-xss-protection: 1
permissions-policy: interest-cohort=()
accept-ch: UA, UA-Mobile, Save-Data, RTT
content-type: text/html; charset=UTF-8
cache-control: max-age=1814400
content-encoding: gzip
content-length: 81
set-cookie: _kagi_search_=EFcQxsHK1oipW2l%2F2te221V7mCG8XXGKxSkGccsQ%2FZ9c%2BWzVINUwezt5C2qrN8zf1a2neuIT4DszGITymY199sRWY4utX89H27souS%2FLAkc%3D--AvHuTeid1ceUJH5jp3ptwOsZHCQ%3D; path=/; expires=Thu, 08 Oct 2043 10:56:58 GMT; Secure; HttpOnly; SameSite=Lax
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
X-Firefox-Spdy: h2
In the response, you can see that the "Content-Type" header is being returned as "text/html; charset=UTF-8". The contents of the data at this url read as the following which shows that it's likely a tracking pixel that was just mistakenly indexed. It's also worth considering that most of the other URLs returned in the image search include a file extension, whereas this one (in particular) does not.
curl -L 'https://kagi.com/proxy/6a01a3fcec1396970b0240a4f8bf85200d-600wi?c=-nDJlTZu1dItIUvn09zADk3WN22uRSasbhLoBrOnZHabSTshkS1QA5wzra7huApZ6MY63cMG-VYdBhsud84F25vPAP-kO6pI3isniBSv_lmrcLI7XcLOxTUQDAxcbIha' | xxd
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452 .PNG........IHDR
00000010: 0000 0001 0000 0001 0806 0000 001f 15c4 ................
00000020: 8900 0000 1049 4441 5408 1d01 0500 faff .....IDAT.......
00000030: 0000 0000 0000 0500 01ba 8910 8a00 0000 ................
00000040: 0049 454e 44ae 4260 82 .IEND.B`.
It's been a while since I've done web-stuff, but something else that's probably worth noting is that I believe because of it rendering as HTML, if an attacker can index an image of their choice that gets mis-rendered (like in the situation that I encountered), a polyglot could likely be used to insert arbitrary javascript into the image which could result in a cross-site-scripting vulnerability for the kagi.com domain.. since it's hosted on kagi.com/proxy/*, anyways.
