How Codex and DeepSeek Agents Automated PaperCut Exploitation From Recon to Linux Sudo Hijacking

Introduction

This post breaks down what the reporting actually claims about how Codex and DeepSeek agents automated PaperCut exploitation, from recon and Windows credential theft to Linux sudo hijacking, and which defenses matter first. Attackers reportedly pointed the tools at PaperCut infrastructure, ran what reporting describes as hundreds of AI agents, and walked away with Windows credentials from roughly 440 servers. The same reporting says they probed a second remote code execution path and used AI-generated scripts to hijack sudo on Linux hosts to capture passwords.

The interesting part is not that a model can write a scanner. Models have been writing mediocre scanners for a while, and exploit automation is not new. What changed is arithmetic. A disposable agent that can be spawned, fail, be rewritten, and spawned again for near-zero marginal cost turns exploitation from a craft into a throughput problem. Defenses tuned to human pacing — a slow, noisy, sequential attacker who gives up — are the ones that break first.

Everything below comes from secondary reporting. There is no primary research paper in front of me, and I will be explicit about where that line sits.

What the reporting establishes — and what it does not

What the seed reporting confirms

Three outlets — CyberSecurityNews, Cyber Press, and GBHackers — all carried items dated 16 October 2026. Across those items, the recurring claims are:

• Codex and DeepSeek are named as the AI tooling used.
• "Hundreds of AI agents" coordinated against PaperCut servers.
• A figure of ~440 PaperCut servers breached worldwide.
• Windows credentials were stolen.
• A "second" RCE attack path was identified.
• AI-generated scripts hijacked Linux sudo to steal passwords.
• CERT-In is referenced in connection with AI-agent-driven attack timelines measured in hours.

Those are the claims as published. They are attributed to the outlets, not to a primary source.

What the reporting does not establish

Here is what the supplied material does not answer, and I will not paper over the gaps with plausible-sounding detail:

Why PaperCut is still a high-value target

The trust boundary that matters

PaperCut is not interesting because it prints. It is interesting because of where it sits. The web admin console manages site servers, MFD and device integrations, and — crucially — directory integration so users can authenticate to printers with their domain accounts. The application ends up holding bind credentials to Active Directory.

That one design fact moves the target. An exposed console is an initial-access surface; the credentials it stores are a relay into the domain. A compromised print server is annoying. A print server that hands over a service account with directory read rights is a different severity class entirely — and that is why "steal Windows credentials" shows up in the headline rather than "deface print jobs."

Prior art that set the pattern

This product family has been on attacker shortlists before, for the same structural reason. In 2023, PaperCut disclosed CVE-2023-27350 (unauthenticated RCE in PaperCut MF/NG) alongside CVE-2023-27351, and both were rapidly exploited in the wild. That history is background for why PaperCut turns up in campaigns like this one. It is not part of the newly reported activity, and I am not claiming the new campaign uses those flaws. The 2023 CVEs are simply the clearest public evidence that the console-to-code-execution path on this product has real precedent.

The agent pipeline, reconstructed stage by stage

The reporting names stages loosely. The mechanics below are my reconstruction of how such a pipeline would be built, using publicly known technique classes. Where I am inferring, I say so.

Recon and fingerprinting

I would expect generated scripts enumerating exposed admin panels, collecting version banners, probing default install paths. The value of an LLM here is not cleverness — it is that one operator can keep twenty enumeration variants running against thousands of targets and regenerate a broken parser in seconds. This is inference from the reported "recon" framing; nothing in the supplied material documents an enumeration workflow.

Credential capture on Windows

If the console is compromised, the plausible path to Windows credentials runs through configuration and integration data: directory bind accounts, service accounts, and stored connection strings for integrated systems. The exact extraction route depends on the flaw, which the reporting does not describe. What I am confident about is prioritization — the credentials are the prize, not the print service.

The second RCE path

"Second path" implies an independent code-execution route: a distinct vulnerable component or a different flaw class, not a variant of the first exploit. The public excerpts name neither. Anyone telling you otherwise right now is guessing.

Linux sudo hijacking via generated scripts

The reported description — generated scripts hijacking sudo to steal passwords — maps onto a well-known post-exploitation pattern. Three common shapes:

1. A fake sudo shim placed in a directory earlier in PATH than /usr/bin.
2. A wrapper script dropped into a user-writable bin directory (~/.local/bin, /usr/local/bin) that logs the password and calls the real binary.
3. A shell function or alias appended to ~/.bashrc or ~/.profile that prompts for and captures credentials.

What "hundreds of agents" buys an attacker

None of this is a new capability. These are old capabilities at a different price. The part of your detection stack that fails first is pacing — the assumption that an attacker will make a handful of attempts and move on.

A safe lab check for your own infrastructure

Test your own environment. The outputs below are illustrative shapes to look for, not captures from the reported campaign.

External PaperCut admin-console exposure

## From outside your network, against a host you own
curl -sk -o /dev/null -w '%{http_code} %{redirect_url}\n' https://print01.example.com:9191/admin
curl -sk https://print01.example.com:9191/admin | grep -io '<title>[^<]*</title>'

If that returns 200 and a title containing the product name, your admin console is internet-reachable. That is the finding. Close it.

Local sudo and PATH integrity

sudo -l
type -a sudo
ls -la /etc/sudoers.d/

type -a sudo printing more than one path is the signal:

sudo is /home/deploy/.local/bin/sudo
sudo is /usr/bin/sudo

A sudo resolving out of a home directory before /usr/bin is a hijack, full stop. Check for writable directories ahead of the system path:

IFS=: read -ra dirs <<< "$PATH"
for d in "${dirs[@]}"; do [ -w "$d" ] && echo "WRITABLE $d"; done

WRITABLE /home/deploy/.local/bin

PaperCut credential exposure on the host

ps -eo user,cmd | grep -i '[p]apercut'
realm list 2>/dev/null   # or: sssctl domain-status <domain>

If the service runs as a domain-joined account with directory read rights, assume a compromise of that host is a compromise of those credentials. Rotate them.

Defenses that change the outcome

PaperCut-specific hardening

Keep the admin console off the internet, or behind an authenticated proxy that logs every session. Patch on the vendor's cadence without debate. Rotate any directory credential the service holds — and rotate it again if you cannot prove the console was never exposed. Alert on new admin sessions from unfamiliar source ranges; that single control catches a lot.

Sudo and PATH integrity controls

Restrict write access to bin directories. Monitor /etc/sudoers and /etc/sudoers.d/ for modification. Watch rc-file writes in home directories. Alert whenever sudo resolves outside expected system paths.

Detecting agent-speed behavior

Rate and concurrency signals are worth having: many near-identical requests, high failed-login volume spread across many hosts, rapid sequential version probes. Be honest about their limits — they overlap heavily with legitimate scanners and with your own vulnerability-management tooling. Alone, they are weak.

What I would fix first

Credential rotation and admin-console exposure reduction beat any "AI detection" control, and it is not close. The AI tooling is not what turns a print-server bug into domain compromise — stolen directory credentials are. Every hour spent building a model-behavior detector while an internet-facing PaperCut console holds a domain service account is an hour spent on the wrong end of the kill chain.

Agent-speed detection is a secondary signal. Useful, cheap to add, and completely unable to save you if the credentials were already valid.

What I confirmed and what I did not test

Confirmed: the reporting exists as described, from three outlets, dated 16 October 2026, with the claims listed in the table above. The 2023 PaperCut CVEs are public and independently verifiable. The sudo hijack patterns described are known technique classes.

Not tested: I have not seen the underlying research, so I cannot confirm the 440 figure, the affected versions, the second RCE mechanism, the specific sudo script, or the degree of agent autonomy. The command outputs above are illustrative shapes, not captures from this campaign. If the primary research is published, several of my inferences deserve re-checking — particularly the credential-extraction route and the recon workflow.

Further Reading

• PaperCut advisory for CVE-2023-27350 and CVE-2023-27351 — vendor security notice
• NVD: CVE-2023-27350 — unauthenticated RCE in PaperCut MF/NG
• NVD: CVE-2023-27351 — authentication bypass in PaperCut MF/NG
• CyberSecurityNews: Codex and DeepSeek AI agents used against PaperCut servers — secondary reporting
• Cyber Press: researchers describe a second PaperCut RCE path — secondary reporting
• GBHackers: hundreds of AI agents used to steal Windows credentials — secondary reporting