Pastejacking is an attack that tricks a user into pasting malicious content or commands into an application, browser, or terminal. The pasted material is often disguised as something harmless, then altered by scripts, overlays, or clipboard manipulation so that the user executes code or reveals data without realising it.
How pastejacking works
Pastejacking succeeds by exploiting a simple trust assumption: people often assume what they paste is exactly what they copied. Attackers break that assumption by changing clipboard contents, masking the true destination, or presenting convincing instructions that make the paste action unsafe.
The technique can target browsers, terminals, chat clients, document editors, or any application that accepts pasted input. The security issue is not the paste itself, but the fact that pasted content can carry active instructions, markup, or commands that behave very differently from what the user expected.
Why pastejacking is effective
Pastejacking is effective because it compresses user attention. Instead of asking a victim to type a malicious command, the attacker only needs the user to perform a routine paste gesture. That reduces friction and makes the malicious payload feel like ordinary workflow output rather than an obvious attack.
It is especially dangerous when the pasted content is meant for a terminal or administrative console, because a single paste can execute multiple commands at once. Even in a browser or text field, the pasted content may trigger script execution, redirect the user, or move them toward credential theft or data disclosure.
Where the security boundary fails
Pastejacking is fundamentally a user-interface trust failure. The clipboard becomes an untrusted transport, and the application receiving the paste may not make the inserted content obvious enough for the user to verify before acting on it. If scripts, overlays, or page logic can alter the clipboard after the user copies it, the user no longer has reliable control over what they are about to execute.
This makes the technique a good example of why visual similarity is not security. A copied command may look harmless in the source view, then arrive with destructive flags, encoded payloads, or extra instructions that were never visible at copy time.
How organisations reduce pastejacking exposure
Defence starts with limiting where pasted content can become execution. High-risk interfaces such as admin consoles, internal tooling, and browser-based shells should make paste actions visible, reviewed, or constrained so that a single paste cannot silently become command execution.
Security awareness also matters, but only as a supporting control. Users need to treat copied commands, installation snippets, and “quick fix” instructions as untrusted until verified. Browser hardening, application validation, and safer terminal handling reduce the chance that a pasted payload can do damage before the user notices. For broader control design, many teams map this kind of user-driven execution risk to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where input handling, auditability, and least-privilege execution matter.
When browser delivery, script injection, or malicious page behaviour is part of the attack path, the threat model overlaps with the OWASP API Security Top 10 only indirectly, but the more direct concern is application trust boundary management rather than API design itself. For terminal abuse and command execution tradecraft, detection and attacker-behaviour mapping are often best understood through MITRE ATT&CK Enterprise Matrix.
Detection and response after suspected pastejacking
Detection often begins with user reports: a pasted string that looked different, an unexpected command chain, or a browser page that behaved strangely after copy and paste. Logging helps when the receiving application records pasted input, command history, or suspicious scripting activity, but many incidents leave little direct trace unless the endpoint or application is instrumented.
Response should focus on what the pasted content may have touched. If a terminal command ran, review shell history, endpoint telemetry, and any outbound connections created by the command. If the paste occurred in a browser or web app, inspect for account session abuse, form submission anomalies, and any follow-on actions that suggest the user was steered into disclosing secrets or authorising an unintended change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Pastejacking can turn one paste into excessive command authority. |
| AU-2 — Event Logging | Pastejacking investigations rely on command and input event visibility. | |
| Recommendation — Limit paste-triggered actions to the minimum privilege needed. Log paste-related and command-execution events for review. | ||
| MITRE ATT&CK | T1204 — User Execution | Pastejacking depends on user-initiated execution of malicious content. |
| Recommendation — Map paste-driven payload delivery to T1204 and hunt for follow-on execution. | ||
| OWASP ASVS | V4 — API and Web Service | Browser and web-app pastejacking risks often surface in input handling and request flow. |
| Recommendation — Validate pasted input paths that can alter requests or trigger unsafe actions. | ||