<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>All research on Crusader Research</title>
		<link>https://crusaderproxy.com/research/en/posts/</link>
		<description>Recent content in All research on Crusader Research</description>
		<generator>Hugo</generator>
		<language>en-US</language>
		
		
		
		
			<lastBuildDate>Sun, 05 Jul 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://crusaderproxy.com/research/en/posts/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Line jumping: how a poisoned MCP tool hijacks a model that was never called</title>
				<link>https://crusaderproxy.com/research/en/posts/mcp-security-auditing-your-ai-tools/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/mcp-security-auditing-your-ai-tools/</guid>
				<description>&lt;p&gt;Most MCP security write-ups tell you each server is &amp;ldquo;a new trust boundary.&amp;rdquo; True, and useless — because it makes you picture a door you choose to walk through. The real problem is that you don&amp;rsquo;t. The dangerous instruction runs the instant you &lt;em&gt;connect&lt;/em&gt; the server, before you invoke anything. &lt;strong&gt;The attack fires at handshake time, not at call time.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Here is the protocol detail that makes MCP different from every integration you&amp;rsquo;ve audited before. When a client connects, it calls &lt;code&gt;tools/list&lt;/code&gt; and the server returns each tool&amp;rsquo;s name, input schema, and a natural-language &lt;code&gt;description&lt;/code&gt;. That description is not shown to the model when the tool is called — it&amp;rsquo;s loaded into the model&amp;rsquo;s context &lt;strong&gt;immediately&lt;/strong&gt;, at &lt;code&gt;tools/list&lt;/code&gt; time, so the model knows which tools exist and when to reach for them. The description is in the prompt from the first token of the conversation onward.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Parameter mining: brute-forcing 65,000 inputs in 40 requests</title>
				<link>https://crusaderproxy.com/research/en/posts/hidden-parameter-mining/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/hidden-parameter-mining/</guid>
				<description>&lt;p&gt;Every endpoint has two input surfaces: the parameters the client sends, and the parameters the server will bind &lt;em&gt;if you happen to name them&lt;/em&gt;. The second surface never appears in your proxy history, never appears in the OpenAPI spec, and never gets a test written against it — which is exactly why the privilege flags and debug toggles live there. A framework binds request fields onto a model. The web and mobile clients populate six of them. The other four — &lt;code&gt;is_admin&lt;/code&gt;, &lt;code&gt;debug&lt;/code&gt;, &lt;code&gt;internal_notes&lt;/code&gt;, &lt;code&gt;account_id&lt;/code&gt; — are wired up, honored, and completely untested because nobody sends inputs they don&amp;rsquo;t know exist.&lt;/p&gt;</description>
			</item>
			<item>
				<title>SSRF past the easy filters: URL-parser confusion and the metadata endpoint</title>
				<link>https://crusaderproxy.com/research/en/posts/ssrf-past-the-easy-filters/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/ssrf-past-the-easy-filters/</guid>
				<description>&lt;p&gt;Server-side request forgery is one of the few bug classes where a single finding hands you cloud credentials. The mechanic is trivial to state — you make a server fetch a URL you control — and every write-up stops there, which is exactly why they&amp;rsquo;re useless. The tutorial payload, &lt;code&gt;http://169.254.169.254/&lt;/code&gt; pasted into a URL field, has been blocklisted everywhere. The reason SSRF is still one of the most productive bug classes in 2026 isn&amp;rsquo;t that developers forgot to filter. It&amp;rsquo;s that &lt;strong&gt;their filter and their HTTP client read the URL differently, and you live in the gap.&lt;/strong&gt;&lt;/p&gt;</description>
			</item>
			<item>
				<title>Tearing the APK apart: the static pass that finds a critical before you set a proxy</title>
				<link>https://crusaderproxy.com/research/en/posts/reading-the-apk-static-analysis/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/reading-the-apk-static-analysis/</guid>
				<description>&lt;p&gt;Most mobile write-ups treat static analysis as the boring prelude — decompile, skim, &amp;ldquo;note any hardcoded secrets,&amp;rdquo; then get to the real work of intercepting traffic. That framing is why testers miss criticals that were sitting in a zip file the whole time. The dynamic pass only shows you what the app does &lt;em&gt;while you drive it&lt;/em&gt;. The static pass shows you the endpoints behind feature flags, the components every other app on the device can reach, and the one Firebase URL that turns into a report before you&amp;rsquo;ve opened a proxy.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Winning web race conditions with the single-packet attack</title>
				<link>https://crusaderproxy.com/research/en/posts/winning-the-race-condition-bugs/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/winning-the-race-condition-bugs/</guid>
				<description>&lt;p&gt;Most write-ups tell you a race condition is a &amp;ldquo;timing window between check and use.&amp;rdquo; True, and useless — because the reason your race attacks fail isn&amp;rsquo;t that you don&amp;rsquo;t understand the concept. It&amp;rsquo;s that &lt;strong&gt;the window is smaller than the internet is precise.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;A typical race window — the gap between an app reading &lt;code&gt;balance&lt;/code&gt; and writing &lt;code&gt;balance - amount&lt;/code&gt; — is measured in &lt;strong&gt;microseconds to a few milliseconds&lt;/strong&gt;. The jitter between two HTTP requests you &lt;em&gt;send&lt;/em&gt; at the same instant, by the time they &lt;em&gt;arrive&lt;/em&gt; and get scheduled on the server, is routinely &lt;strong&gt;1 to 10 milliseconds&lt;/strong&gt;, and worse across the public internet. So your &amp;ldquo;simultaneous&amp;rdquo; requests arrive in a neat little line, the server processes them one at a time, the limit holds, and you conclude the endpoint is safe. It isn&amp;rsquo;t. You just lost the race to network jitter before the server ever got a vote.&lt;/p&gt;</description>
			</item>
			<item>
				<title>IDOR lives in the second identifier: finding BOLA with two-account Shadow Replay</title>
				<link>https://crusaderproxy.com/research/en/posts/finding-idor-bola-with-shadow-replay/</link>
				<pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/finding-idor-bola-with-shadow-replay/</guid>
				<description>&lt;p&gt;Every IDOR tutorial hands you the same drill: find &lt;code&gt;/api/orders/48210&lt;/code&gt;, change it to &lt;code&gt;48211&lt;/code&gt;, look for a &lt;code&gt;200&lt;/code&gt;. That drill trains you to attack the one identifier the application is most likely to check. The primary key in the URL path is where the framework&amp;rsquo;s &lt;code&gt;@authorize&lt;/code&gt; annotation lives, where the ORM scopes the query, where the review focused. It&amp;rsquo;s the honeypot. You fuzz it, get &lt;code&gt;403&lt;/code&gt;s, call the endpoint safe, and walk right past the bug.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Indirect prompt injection is SSRF for the agent era</title>
				<link>https://crusaderproxy.com/research/en/posts/prompt-injection-is-the-new-ssrf/</link>
				<pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/prompt-injection-is-the-new-ssrf/</guid>
				<description>&lt;p&gt;Most write-ups tell you prompt injection is &amp;ldquo;when the model follows instructions in its input.&amp;rdquo; True, and useless — because that framing makes it sound like a chatbot quirk you patch with a better system prompt. It isn&amp;rsquo;t. It&amp;rsquo;s an architecture bug you already know by another name.&lt;/p&gt;&#xA;&lt;p&gt;SSRF happened because a server would fetch a URL &lt;em&gt;you&lt;/em&gt; controlled and trust the &lt;strong&gt;response&lt;/strong&gt;. Indirect prompt injection happens because an agent reads content &lt;em&gt;you&lt;/em&gt; control — a web page, a PDF, an email, a calendar invite — and trusts it as &lt;strong&gt;instructions&lt;/strong&gt;. Same defect, new medium. The server-side fetch became a model-side read; the trusted response became a trusted command.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Android 14 CA move that broke every &#39;/system/etc&#39; pinning tutorial</title>
				<link>https://crusaderproxy.com/research/en/posts/intercepting-mobile-apps-that-fight-back/</link>
				<pubDate>Thu, 02 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/intercepting-mobile-apps-that-fight-back/</guid>
				<description>&lt;p&gt;Ninety percent of mobile testing is web testing you already know — REST, tokens, IDOR, injection. The other ten percent is a wall you hit before you can do &lt;em&gt;any&lt;/em&gt; of it: getting the app&amp;rsquo;s HTTPS traffic to land in your proxy as plaintext. And most write-ups get that ten percent wrong, because they were written for an Android that no longer exists. You follow the steps, the cert goes into &lt;code&gt;/system&lt;/code&gt;, the app still throws handshake errors, and you conclude the app has exotic pinning. It doesn&amp;rsquo;t. &lt;strong&gt;Google moved the trust store out from under you and the tutorial never noticed.&lt;/strong&gt;&lt;/p&gt;</description>
			</item>
			<item>
				<title>The richest recon target is a file you already downloaded</title>
				<link>https://crusaderproxy.com/research/en/posts/passive-recon-from-proxy-history/</link>
				<pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/passive-recon-from-proxy-history/</guid>
				<description>&lt;p&gt;Most recon writeups open with a subdomain brute-force and a wordlist. That&amp;rsquo;s fine, but it&amp;rsquo;s loud, it&amp;rsquo;s slow, and it runs &lt;em&gt;before&lt;/em&gt; you understand the app. The problem isn&amp;rsquo;t that people don&amp;rsquo;t know how to enumerate — it&amp;rsquo;s that they treat recon as something you go &lt;em&gt;out&lt;/em&gt; and do, when the highest-yield artifact is already sitting in your proxy history. &lt;strong&gt;You downloaded the whole codebase the moment the page loaded. You just haven&amp;rsquo;t read it yet.&lt;/strong&gt;&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
