I’m Chris, one of PaperCut’s founders, the CEO, and still very much a tech guy at heart.
Over the past few days, I’ve been working with our security and engineering teams through an active security incident affecting PaperCut NG/MF. Although I don’t write the patches or analyze every log, I do work alongside the very capable people doing… mostly with far less sleep than I’d recommend.
One useful thing (in addition to making them coffee) I can do while the teams are racing away, is take a few moments to write to you all and explain what has been happening behind the scenes, and why we’ve made some of the decisions we have.
This is not the full technical account. The incident is still active, we are still investigating and hardening, and there may be further updates. Once the dust settles, we’ll publish a proper technical retrospective, as we did after the 2023 incident.
For now, this is the story so far…. but if you haven’t read the advisory, please do so now!
The first report
At 9:42 a.m. AEST (UTC+10) on Thursday the 27th of August 2026, a report arrived from an Education sector customer whose PaperCut MF server appeared to have been compromised.
Our first question was fairly mundane: was the server fully patched?
We initially looked at whether this might be an “n-day” attack - an attacker using a vulnerability we already knew about and had fixed in a later release.
But the evidence didn’t fit.
The logs pointed to a different path, and they showed real code execution on the server. By midday, the level of concern inside our teams was rising quickly. We declared a P0 incident and were operating on the assumption that we were dealing with a previously unknown vulnerability being actively exploited in the wild - often referred to as a zero-day attack. There was enough context in the logs to at least hint at a possible area of code that might be part of an exploit chain. We focused on trying to identify potential chains and reproducing the exploit along this “hint of a path”.
That kicked off a fairly dramatic change of plans for a lot of people at PaperCut.
Why we moved so quickly
The 2023 PaperCut security incident was front of mind.
One of the biggest lessons from that incident was that the first attacker is not necessarily the biggest part of the problem. In 2023, the initial exploitation round was serious, but much of the broader damage came later. Once enough information about the 2023 n-day vulnerability became public, additional hacker groups moved in, including state-sponsored actors, and began exploiting exposed servers at scale.
So our concern was not only the activity we had already seen at one customer.
It was what might happen next if other attackers learned enough to reproduce it while potentially thousands of customers were still exposed.
That led us to two immediate priorities:
- Ask customers to temporarily remove internet-facing PaperCut Application Servers from the internet using our security alert systems.
- Get a practical mitigation into customers’ hands as quickly as we could.
At that stage, we did not understand the full exploit chain. We did not know how widely the technique was known, whether it had been shared between groups, or whether more attackers were already trying to reproduce it.
We assumed the worst and acted accordingly. Communications were very direct and fairly dry. They focused on what customers should do, not on telling the story.
The customers who helped us understand it
The first education sector customer had an excellent security and digital forensics and incident response team (DFIR).
Its intrusion-detection systems picked up suspicious behavior quickly, and the affected virtual machine was isolated almost immediately. That preserved logs and forensic evidence that might otherwise have disappeared. These logs gave us the initial hint on the exploit chain path.
A second organization in the same region reported similar activity later on Thursday afternoon at 5:05 pm. Fortunately they were able to capture more information, including additional logs and details, that helped us fingerprint and fully reconstruct much more of the exploit chain and attack. Bingo!
Both customers, and their respective DFIR teams, were extraordinarily helpful. They joined calls, shared evidence, and worked with our people, all while dealing with their own incidents.
They also seemed to understand that this was bigger than their own organizations. The evidence they provided could help protect thousands of other customers.
We are very grateful to them, and to the other customers who have since reported suspected or confirmed compromises. Their controls (EDR, etc.) did not necessarily stop the initial exploit, but they detected it quickly, limited the attacker’s time on the server, and preserved the evidence that helped us protect everyone else.
So far, the activity appears to have been relatively focused and limited. But we are still working with customers, security researchers, and partners to understand the full breadth of impact. It is too early to draw a hard boundary around it.
Swarming the problem
Once we declared the P0 (drop everything level), the response split into parallel streams.
One group worked on reconstructing the exploit and internal red teaming. Others focused on mitigations, patch development, release engineering, testing, customer communications, and identifying public-facing servers.
We also used a mix of system-usage data, licensing data, and public scanning tools to identify customers that appeared more exposed than others, so we could begin proactive outreach while broader alerts went out through our security mailing list and in-product emergency notifications (a feature added after the 2023 incident retro).
The first 48 hours were intense.
People worked through the night. Engineers rotated in and out, sometimes returning after a few hours’ sleep to find that another team, or an external researcher in a different time zone, had uncovered something new. We were not only trying to reproduce and block the attack we had already seen. Other teams were searching for variants, adjacent paths, and ways an attacker might bypass the first mitigation.
This is one of those situations where the normal org chart becomes largely irrelevant. People with the right skills jump in, form small groups, test ideas, challenge assumptions, and keep moving.
It is exhausting, but it is also pretty amazing to watch.
Why there have been multiple patches
We know that asking customers to patch several times is disruptive.
Administrators need change-windows. Upgrades take planning. Some customers have experienced regressions. None of that is lost on us.
The blunt explanation is that we chose to release useful protection as soon as we had it, rather than wait for a single perfect fix while customers remained exposed. While at the time we hadn’t seen widescale automated exploitation, we were worried it was only a matter of time. Our experience in 2023 told us that the bigger wave could come later, once other groups understood the vulnerability. Our initial response was intended to break the known attack path, protect exposed customers, and buy time to address the issue more completely.
Our normal build and test process is highly automated, but a lot of our testing is “manual with real printer hardware”. We bypassed manual testing to rush mitigations to customers who might not be able to remove their servers from the internet.
We also decided to backport the mitigations to several older PaperCut NG/MF release lines so that many customers could take a smaller upgrade step rather than being forced onto the latest major version during an emergency.
The first release was an emergency mitigation. The next release added further hardening as we understood more. We have additional work in hand, and there may be further Emergency Patch releases if required, and of course, a final fully QA and regression-tested official release soon.
That can look messy from the outside because, frankly, incident response is messy.
The alternative was to hold everything back until we believed we had a complete answer. Based on what we learned in 2023, we did not think that was the safer choice. Patch fatigue is real, but when there is credible evidence of active exploitation in the wild, we will always prefer to make an emergency mitigation available quickly rather than delay it. Customers can then make the right operational decision for their environment, but in our opinion, they should at least have the information and options to protect themselves.
What the exploit looked like
We are deliberately not publishing the full technical chain yet.
At a high level, this was not a vulnerable third-party library or a simple dependency problem. It involved an authentication bypass in the core product, followed by a complex, multi-stage exploit chain that led to remote code execution.
One part of the chain leveraged a rarely used PaperCut feature that can look up card numbers from an external database. The attackers combined database-driver behavior, chained with arbitrary file-writing capabilities and Java class loading to place and execute their own payload.
It was a clever chain.
I also need to put my hand up here: the authentication-bypass part at the start of that chain came from code I personally have contributed to over the years.
That is not an especially comfortable thing to write, but it is the truth. Any code does not become harmless simply because it has been running for a long time or has been through multiple pen tests and security audits, which it has. Sometimes it sits quietly until someone finds a way to combine it with other behaviors in a way nobody originally imagined - something that’s only accelerating with AI.
We don’t know anything about the hackers or their motivations. We will publish the full technical reconstruction, and collective findings from customers and researchers, when doing so is unlikely to create more risk.
Working with security researchers
The security research community has been a major part of the response.
Researchers, including teams at watchTowr, Huntress, and other independents, analyzed activity affecting their customers and tested our emergency mitigations. In some cases, they found areas where additional hardening was needed.
The time-zone difference helped.
While our Australian engineers were getting some sleep, work never stopped with researchers elsewhere continued pulling things apart. Our teams would come back online to new findings, test cases and questions.
That kind of collaboration is extremely valuable during an active incident. It’s still ongoing right now as I write this post.
It is also something we are better at now because of 2023 security incident. We have stronger relationships with researchers, better internal processes, and a much clearer understanding that independent scrutiny makes the product stronger.
Why we didn’t say more at the start
A fair criticism is that our early updates did not explain much about what was happening.
That was deliberate, although we will review whether we got the balance right once we are past the worst of this. Please provide us with feedback, as your opinions matter.
During the first 48 hours, we were trying to avoid publishing information that might help additional attackers while customers were potentially still exposed. Even apparently minor technical clues around Indicators of Compromise (IoC) can narrow the search space for someone trying to recreate an exploit.
So we prioritized action: take the server off the public internet. Apply the mitigation. Watch the advisory.
The storytelling came second.
We will ask external researchers for their views on whether we communicated enough, early enough. We will also look at what we could do differently next time.
At the time, our concern was simple: get customers out of harm’s way.
What changed after 2023
After the 2023 incident, we put a huge amount of effort into security.
We expanded our internal capability, increased testing, and worked with some of the best security researchers in the world. That led to a significant period of vulnerability discovery and remediation across PaperCut NG/MF. A lot of CVEs were found, fixed and shipped, and the product became materially stronger because of that work.
And yet this exploit chain was not found during that uplift.
That is humbling.
It also demonstrates something important about complex software: vulnerabilities often do not live in one obviously bad line of code. They emerge from the interaction of several individually reasonable features.
The post-2023 work was still enormously valuable. Those investments did not find this particular chain, but they meant that when the report arrived at 9:42 a.m., we already had the people, relationships, communication channels, and war-gamed incident processes needed to move quickly.
But security is never finished. And as LLMs/AI make it faster for both defenders and attackers to search codebases, generate hypotheses and connect obscure behaviors, I suspect that lesson is only going to become more important.
What happens next
The incident is still active.
We are continuing to investigate, test and harden. Further releases or advisory updates may follow.
Our current advice remains:
- Follow the containment guidance in our advisory. IMPORTANT: This will be kept current and is the source of truth.
- Avoid exposing the Application Server directly to the internet unless it is operationally necessary and protected with appropriate layers of security.
- Subscribe to the PaperCut security mailing list.
- Keep watching the advisory for updates.
We also intend to share more practical guidance on defence in depth. Some of the education sector security teams we have worked with have excellent examples of strong monitoring, rapid containment and good forensic readiness. There are a lot others can learn from them.
After the immediate risk has passed, we will publish a more complete technical retrospective and post-incident report. As part of this, we will review our own response: the patches, the regressions, our communication, and the decisions we made under pressure. Most importantly, we’ll also review what we’ve learned… and what will change.
But I did want customers to know that behind the fairly terse advisories, there is a large group of people working very hard, making difficult calls and trying to protect customers as quickly as possible.
And to the customers and researchers who have helped us do that: thank you. We understand the time this has taken and we thank you for your quick response.
I will personally commit to sharing more of the story when the dust settles.
