A bait-and-switch attack lures a user, agent, or system into trusting one thing and then silently changes what is delivered or executed. In security, this can redirect authentication, permissions, downloads, or prompts to a malicious substitute, defeating user intent and control across identity, application, and supply chain workflows.
How a bait-and-switch attack works
A bait-and-switch attack creates trust in an initial, benign-looking target and then swaps in a different payload, destination, or permission path after the user or system has already committed. The dangerous part is the silent change of delivery, which makes the later action feel like a continuation of the original one.
This pattern is effective because security decisions often happen in stages: a prompt is shown, a link is clicked, a package is fetched, or a consent screen is accepted before the final action occurs. Once the attacker controls the last step, the original user intent no longer protects the outcome.
Where the switch happens
Bait-and-switch attacks can appear in web pages, installers, application stores, API flows, browser redirects, and agent tool chains. The bait may be a legitimate login, a normal download, a harmless prompt, or a trusted brand, while the switch occurs through a redirect, a late-stage script change, a poisoned dependency, or a substituted authorization target.
The most damaging versions exploit timing and trust boundaries. A page may look safe during inspection but deliver malicious content after a redirect, an update process may replace a signed or expected component, or an assistant may be shown one task and then routed to a different endpoint that exposes credentials or data.
Because the attack works by changing what is actually executed or delivered, it can undermine both human review and automated verification if the environment only checks the first step. That makes it relevant wherever the boundary between selection and execution is weak.
Why it is dangerous for identity and supply chain workflows
The attack is especially hazardous when the swapped target affects authentication, permissions, tokens, or software delivery. A user may believe they are approving a normal action, while the substituted destination captures credentials, requests broader consent, or installs a malicious component that inherits trust from the original path.
Supply chain contexts are particularly exposed because a trusted package name, update channel, or dependency reference can be retained while the actual artifact, source, or script changes underneath it. In identity-heavy environments, the same pattern can redirect a legitimate sign-in or approval flow into a fraudulent one that steals sessions or grants access.
For a deeper view of how attackers abuse trust in non-human and machine-driven environments, see The State of NHI & AI Agent Breach Report 2026.
How organisations reduce exposure and verify compromise
Defence starts with making the expected destination and the actual destination harder to separate. Organisations should compare what was requested, what was displayed, and what was ultimately executed or fetched, especially for downloads, redirects, consent flows, browser extensions, and automated agent actions.
Detection should focus on mismatches: unexpected redirects, modified payload hashes, changed domains, altered permission scopes, unusual install sources, or prompts that do not align with the initiating action. If a bait-and-switch event is suspected, review what credentials, sessions, keys, or approvals may have been exposed after the switch.
Authoritative threat intelligence and technique mapping can help teams recognise these patterns in active campaigns, including CISA cyber threat advisories and the MITRE ATT&CK Enterprise Matrix, which helps map the follow-on behaviours that often accompany deceptive delivery and execution changes.
Risk and Threat Considerations
Bait-and-switch attacks are risky because they exploit a gap between trust formation and final execution. The user, application, or agent believes it is approving one thing, but the attacker replaces the object of trust at the moment that matters most.
Failure mechanism: The defender validates the bait, but not the final delivered object, so a late-stage redirect, replacement, or substitution succeeds without triggering the original trust decision.
Impact: Credentials can be stolen, permissions can be expanded, malicious code can be installed, and compromised sessions or downstream systems can be abused as if the action were legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Bait-and-switch relies on deceptive delivery and trust abuse to induce a harmful action. |
| Recommendation — Map deceptive delivery patterns to T1566 and inspect the final destination before trust is granted. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The attack succeeds when systems fail to validate the final object or destination after a trusted start. |
| Recommendation — Validate final inputs and destinations before execution or approval. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Swapped routes, redirects, and trust-boundary changes often exploit weak API or deployment configuration. |
| Recommendation — Harden routing and deployment settings so a trusted entry point cannot silently redirect to a malicious target. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Bait-and-switch can redirect authentication or consent into a fraudulent authorization flow. |
| Recommendation — Verify redirect targets and consent destinations before exchanging identity tokens or granting scopes. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The attack often lands through compromised software delivery or substituted application content. |
| Recommendation — Control software provenance and verify delivered artifacts before deployment or use. | ||
Practitioner Guidance
Why practitioners should care: Treat the gap between initiation and execution as a control point, not just the visible prompt or link. If the final destination, binary, or action can change after approval, the security decision is incomplete.
What to watch for: Watch for redirects, last-mile content swaps, unsigned or unexpectedly changed artifacts, and prompts that request broader access than the original context would justify. In practice, the safest review is the one that verifies the final target, not only the starting point.