<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Relevanssi on Jack Taylor</title><link>https://jacktaylor.tech/tags/relevanssi/</link><description>Recent content in Relevanssi on Jack Taylor</description><generator>Hugo</generator><language>en</language><managingEditor>jack@jacktaylor.tech (Jack Taylor)</managingEditor><webMaster>jack@jacktaylor.tech (Jack Taylor)</webMaster><lastBuildDate>Sun, 12 Apr 2026 00:47:49 +0900</lastBuildDate><atom:link href="https://jacktaylor.tech/tags/relevanssi/index.xml" rel="self" type="application/rss+xml"/><item><title>How I found SQL injection on 100,000 WordPress sites</title><link>https://jacktaylor.tech/2026/04/how-i-found-sql-injection-on-100000-wordpress-sites/</link><pubDate>Sun, 12 Apr 2026 00:47:49 +0900</pubDate><author>jack@jacktaylor.tech (Jack Taylor)</author><guid>https://jacktaylor.tech/2026/04/how-i-found-sql-injection-on-100000-wordpress-sites/</guid><description>&lt;p&gt;I recently reported an unauthenticated &lt;a href="https://en.wikipedia.org/wiki/SQL_injection"&gt;SQL injection&lt;/a&gt; in &lt;a href="https://www.relevanssi.com/"&gt;Relevanssi&lt;/a&gt;, a WordPress search plugin that was active on more than 100,000 sites. There were two things that made this bug especially fun to work on: first, a type confusion issue where input that only &lt;em&gt;looked&lt;/em&gt; like a numeric term ID could carry extra SQL with it, and second, an exploitation trick where one SQL injection payload was smuggled inside another in order to get around the limitations of the first query.&lt;/p&gt;</description></item></channel></rss>