A CV almost got me hacked? Yup. Wild, but true.

After 11 years in recruitment, reviewing thousands of applications through applicant tracking systems, I thought I'd seen everything. Bizarre formatting. Attachments named final_FINAL_v3_REAL.pdf. Resumes written entirely in Comic Sans.

But I hadn't seen this.

The Printer That Betrayed Me

Last week, I was reviewing candidate profiles in our ATS when something strange happened. I opened a PDF resume - a normal-looking CV from what appeared to be a legitimate applicant - and my printer started running.

No click. No prompt. No "are you sure?" dialog. Just the sudden whir of paper feeding through the machine, unprompted.

My first thought was that I must have fat-fingered a keyboard shortcut. Ctrl+P happens to the best of us. But something felt off. I hadn't touched the keyboard. The file had just... opened.

I cancelled the print job and did what any paranoid person would do. I uploaded the PDF to VirusTotal.

What came back made my stomach drop.

Not a Bug - A Weapon

The sandbox analysis flagged the file as malware. But this wasn't some amateur-hour virus from 2005. The detection report read like a cybersecurity horror movie.

The malware could steal credentials - harvesting passwords and authentication tokens directly from the operating system. It could install a rootkit, burying itself deep enough to survive reboots and hide from casual inspection. It could hijack running processes, injecting malicious code into legitimate applications so nothing looked out of place.

But it got worse.

The malware could disable antivirus. It contained techniques to manipulate Windows Defender policies and blind security tools before they could react. It was sandbox-aware, meaning it could detect when it was being analyzed and behave innocently until the coast was clear. It had encrypted command-and-control channels to phone home to attacker infrastructure. And as a bonus, it included resource hijacking capabilities - probably a cryptominer running in the background to generate revenue while it waited for instructions.

This wasn't a prank. This was a multi-stage, defense-aware, credential-stealing toolkit disguised as a job application.

Why Did My Printer Go Off?

Here's the twist. The printing wasn't the attack. It was a side effect.

Looking at the sandbox's process tree, the malicious PDF spawned Adobe Acrobat, which then wrote files to the Windows print spooler directory and triggered the print subsystem. The exploit chain was executing through Acrobat's PDF rendering engine, and the printer activity was just collateral noise from that execution.

In other words, I got lucky. The weird behavior exposed the attack before the real payload could deploy. If the exploit had been cleaner, or if I'd been less paranoid, I might never have noticed until it was too late.

I Reported It. The Response Was... Something.

I contacted Teamtailor, the ATS platform that had processed and served this file to me. Surely they'd want to know that a malware-laced document had passed through their system undetected.

Their response was memorable.

They told me to ask the candidate to upload a new, virus-free version of their CV.

I read it twice to make sure I understood correctly.

Their security protocol for a malware incident was to ask the attacker to please send a nicer attack. No file quarantine. No retroactive scan. No acknowledgment that their platform had just served malware directly to a paying customer. Just ask the candidate to try again.

This Is Bigger Than One Bad PDF

Applicant Tracking Systems process millions of files every day. Resumes, cover letters, portfolios, certifications - all uploaded by strangers on the internet, all opened by employees on corporate networks.

And yet, most ATS platforms treat these files as inherently safe.

There's no antivirus scanning on upload. No sandboxing before preview. No stripping of embedded scripts, macros, or executable code. No warnings to the end user about file origin or risk.

The assumption is that a PDF from a job applicant couldn't possibly be dangerous. But attackers don't care about your assumptions. They care about your blind spots. And right now, recruitment pipelines are a massive blind spot.

The Attacker Knew What They Were Doing

This wasn't a spray-and-pray campaign. Someone built this malware specifically to get past corporate defenses. It had sandbox evasion to detect analysis environments. It had EDR bypass techniques to disable endpoint protection. It had encrypted communications to hide its traffic. It had multiple persistence mechanisms so it wouldn't go away easily.

And they chose a job application as the delivery mechanism because they knew it would work.

The applicant profile looked real. It's possible the person was themselves a victim, their identity or account compromised to distribute the payload. I can't confirm either way. But that ambiguity is part of what makes this attack vector so effective. You can't just block suspicious applicants, because the profile looks completely normal.

What Should You Do?

If your company processes job applications - and almost every company does - you need to ask some uncomfortable questions.

Does your ATS scan uploaded files for malware? Have you ever asked? What happens when a malicious file is detected? If the answer is "we ask the candidate to upload a new one," you have a problem.

For IT and security teams, the question is whether candidate uploads are treated as untrusted input. Do they go through the same scrutiny as email attachments? Is there any sandboxing or isolation before files reach end users?

And for ATS vendors themselves, what is your malware scanning policy? Do you strip embedded code from PDFs and Office documents? What does your incident response actually look like when something slips through?

If you don't like the answers, or if there are no answers, that's a red flag.

The Real Lesson

Attackers evolve. They find the paths of least resistance. And right now, the path of least resistance runs straight through your careers page.

A job posting is an open invitation. Anyone in the world can respond, attach a file, and have that file processed by your internal systems. It's a feature, not a bug. But it's also a massive attack surface that most organizations aren't thinking about.

This incident didn't compromise my system because I got paranoid about a printer. Most people wouldn't have noticed. Most people would have clicked through, assumed it was a glitch, and moved on while a rootkit quietly installed itself in the background.

I got lucky. The next company might not.