The Difference Between Updated, Remediated, and Clean

For two weeks starting on August 27, 2026, a PaperCut administrator could not answer the question "is this server patched" by looking at its version number. The emergency builds PaperCut shipped during the incident reported the same version as the unpatched releases they were based on. The numbered builds that the CVE records had been naming as the fix since August 28 did not exist until September 10.

The incident itself has been covered well. Huntress documented the pre-auth RCE chain and the activity on compromised hosts. GreyNoise tracked a campaign against internet-facing servers. PaperCut's co-founder and CEO published an unusually frank account of the response.

Less attention went to the part that decides whether any of the patching worked. Updated, remediated, and clean are three different states. Most vulnerability management programs measure the first, report it as the second, and never test for the third. The gap between the first two is where patch management and vulnerability management get conflated.

PaperCut is a useful case because it broke at all three layers inside two weeks, and because none of the breaks were anybody's fault in particular.

What happened with PaperCut NG and MF?

PaperCut NG and PaperCut MF are on-premises print management platforms. PaperCut's site reports over 100 million users at over 70,000 organizations. These servers sit in the middle of a print estate, commonly hold directory credentials, and accept inbound connections from workstations across the building.

The vendor's timeline, in Australian Eastern Standard Time, which is how PaperCut published it:

Two things in that table matter more than the rest. A customer reported an incident before the advisory existed. And the release that finally carried the version numbers the CVE records had been citing as "fixed" landed thirteen days after those records published.

Why is "updated" a moving target?

Emergency patching a production print server once is hard. Someone has to find the change window, send the maintenance notice, and be there when the service does not come back cleanly. Doing it four times in two weeks is a different kind of problem.

The deeper issue is that during those two weeks, "updated" was not observable. PaperCut's emergency patch builds reported the same version number as the unpatched release they were based on. A server patched within hours of Release 1 and a server nobody had touched returned the same version string to any tool that asked. PaperCut added build numbers to the emergency patch downloads on September 1, so a pipeline keyed on the build number could tell the two apart from day five. A pipeline keyed on the version string was blind for thirteen days.

The vendor did the pragmatic thing. Shipping a fix in hours is worth more than shipping a fix with clean version metadata in a week. But the cost landed on the people who had to prove the fix was in place.

Meanwhile the rest of the queue did not pause. Between August 28 and September 9, another 2,522 CVEs published with a CVSS score of 7.5 or higher on whichever scale they carried.

The KEV column covers CVEs that published in the window, whenever CISA added them. CISA also added older CVEs to KEV over the same days, and the count leaves those out because they published before August 28. The twelve in-window CVEs with no connection to PaperCut:

Note the no-score column in the previous table. In the September 2 to September 9 window, 215 records still carried no CVSS score at all six days after the window closed. A program that triages on severity has no input for those until somebody enriches them, and enrichment is the step that has been degrading fastest. That degradation is why CVEs now function as a trailing indicator rather than an early warning.

Why does "updated" not equal "remediated"?

Remediation means the vulnerable condition is gone and you can prove it. Proof needs a fixed-version boundary you can trust. For these two CVEs, three separate sources give three different answers.

The CVE record puts three versions in a field that holds one

Here is the affected block as both records published it on August 28, identical in each. The cvelistV5 repository still holds that version at its September 1 commit (CVE-2026-81578, CVE-2026-82078):

"affected": [
  {
    "vendor": "PaperCut",
    "product": "PaperCut MF/NG",
    "versions": [
      {
        "status": "affected",
        "version": "0",
        "lessThan": "24.1.10, 25.0.13, 26.0.5",
        "versionType": "semver"
      }
    ],
    "defaultStatus": "unaffected"
  }
]

The lessThan field holds a single version. This one holds three, comma-separated, declared as semver. There is no semantic version equal to "24.1.10, 25.0.13, 26.0.5". PaperCut maintains three supported branches and the fix landed in each, which is a reasonable thing to communicate and the wrong field to communicate it in. The CVE v5 schema expects one range entry per branch.

Running both records through cvelint, an open-source validator for CVE v5 JSON records written by Martin Prpič, returns the same two findings on each:

E007  Version "0" does not match expected format for type "semver"
      (at "containers.cna.affected.0.versions.0.version")
E007  Invalid lessThan version string: "24.1.10, 25.0.13, 26.0.5"
      (at "containers.cna.affected.0.versions.0.lessThan")

PaperCut corrected both records on September 13, sixteen days after publication. The affected block now carries three range entries, one per branch, and each lessThan holds a single version. NVD's derived ranges did not follow.

NVD resolved it one release short

This is where the malformed field stops being a data-hygiene footnote. NVD built CPE applicability ranges for both CVEs using versionEndExcluding values of 24.1.9, 25.0.12, and 26.0.4, for both papercut_mf and papercut_ng.

Those are the releases immediately before the fixes. A tool that takes NVD's CPE ranges as written marks a server running 25.0.12 as not affected. 25.0.12 is vulnerable. The fix is 25.0.13. NVD modified both records again on September 14, after PaperCut's correction, and kept the short ranges.

A dashboard that goes green on that comparison has proven one thing: a string comparison succeeded against a range somebody derived from a field that could not be parsed.

Even the weakness classification disagrees

The CVE record for CVE-2026-81578 assigns CWE-305, Authentication Bypass by Primary Weakness. PaperCut's own security bulletin classifies the same flaw as CWE-306, Missing Authentication for Critical Function. CISA's KEV entry follows the vendor and titles it as missing authentication.

The severity does not agree either. CVE-2026-81578 scores 8.8 on CVSS v4, assigned by PaperCut, which is high. NVD assigned it 9.8 on CVSS v3.1, which is critical. PaperCut published no v3 score. Whether this CVE is classified as critical depends entirely on which scale your tooling reads.

How common is this?

Common enough to be a property of the corpus rather than a PaperCut mistake. Spektion ran cvelint v0.7.0 across every published 2026 record in the CVE Project cvelistV5 release bundle of September 15, 2026, with the 858 rejected records set aside.

Two caveats keep this honest. A lint finding is not automatically a schema violation, and E007 in particular also fires on the benign use of "0" rather than "0.0.0.0" in a version field, which is nothing like the PaperCut defect. Separating the two: 7,255 of the 33,015 records trip E007 on nothing but that bare zero, and 25,760 carry some other version string the rule cannot parse. Read the table as a statement about where the corpus is noisiest, version metadata, rather than as 33,015 broken records. That noise makes version-based remediation proof the least reliable form of proof on offer.

This is a different failure from the one Spektion Research documented in its September pull on CPE coverage, where the problem was records carrying no CPE at all. Here the field exists and is populated. It does not mean what a parser assumes. Both failures land on the same team.

What does "clean" mean?

Clean is the question a patch cannot answer. A patch changes the server from the moment it lands. It says nothing about what happened on that server before.

For PaperCut, "before" was real time. A customer reported the first incident to PaperCut at 9:42 a.m. AEST on August 27. Emergency Patch Release 1 shipped for the v25 and v26 branches at 2:10 a.m. on August 28, and the v24 build followed at 10:08 p.m. that night. By Spektion's arithmetic from the vendor's own timestamps, that is about 16 hours from first report to first fix on v25 and v26, and about 36 hours on v24. Huntress documented a v24.1.5 server exploited before Emergency Patch Release 2 was publicly available. Version 23 and earlier received no patch at all.

What access looked like

PaperCut's bulletin lists what investigators found on affected servers:

• Discovery commands, including whoami, tasklist, quser, and nltest /dclist:
• A deleted server.log
• A downloaded ace.exe, and an AnyDesk download
• A Windows service named "Remote Access Service": a SimpleHelp remote access tool running as LocalSystem and set to start automatically

That last item decides the argument. Upgrading PaperCut replaces PaperCut's code. It does not uninstall a Windows service someone else installed, and a remote access tool set to start on boot survives every release the vendor ships.

The vendor is explicit that its list is not a clearance test. The bulletin says the absence of its indicators "is not confirmation that a system has not been affected," and it warns that attackers may clean up the files it lists. For a server that may be compromised, its guidance is a full wipe and rebuild, restored from a backup taken before any suspicious behavior. Huntress adds the operational warning: preserve evidence before an upgrade or restart changes it.

GreyNoise's campaign analysis shows what that kind of access turns into. Across at least 440 PaperCut instances at 395 victim organizations, the actor harvested credentials, dropped a Ligolo tunnel agent for persistent access, and reached domain administrator at 12 organizations, dumping each domain's credential store with DCSync. That campaign began August 31, so it describes what access became, not a compromise that outlived a patch. A server that was entered and then patched carries the same exposure until someone looks.

Where runtime evidence fits

Most organizations will not wipe and rebuild every PaperCut server on suspicion alone. The practical question is which hosts to open first, and the runtime dimensions answer it. Spektion's sensor grades software on those dimensions as it executes:

• Execution state. Did the print service run during the exposure window? A host where it sat installed and idle belongs at the bottom of the investigation queue and at the top of the removal queue.
• Privilege level. What did it run as? The remote access service in PaperCut's bulletin ran as LocalSystem. A new process at that privilege on a print server is the first thing to look for.
• Network exposure. Was the web management interface reachable from the internet, or only from a restricted range? PaperCut's advisory told customers to restrict web access to trusted IP addresses, a network-exposure control offered alongside the patch.
• What it could reach. What could the service account reach afterward? One of GreyNoise's three attack paths depended on PaperCut running as a Domain Admin service account.

On a PaperCut application server, that evidence is a short record covering the two weeks: whether the application service executed, which account it ran under, whether its web interface held a listening socket reachable from outside the trusted range, and what that account could reach. Spektion matches PaperCut builds against the same catalog every scanner uses, so for those thirteen days its match, like everyone's, could not separate a patched build from an unpatched one. Patch verification stays with the patch tool. The runtime evidence changes the order of the queue, and the reason for each position travels with the finding. A server that ran the service as a domain administrator behind an internet-facing interface ranks above one where the service never started, and that ranking holds whether or not the version string can be trusted.

The same evidence feeds the controls that hold a host while the patch is in flight: OS configuration changes that cut the service's privilege and network reach, and detection rules for the SIEM or EDR built from the PaperCut process's observed behavior, so an exploitation attempt registers at the first stage of the chain instead of after the remote access tool is installed. Each control ships with steps to verify it took, which for two weeks was the one state on a PaperCut server a team could check.

How do you tell the three apart?

Three things a team can carry into the next incident:

1. Treat the vendor advisory as the fixed-version source of truth. Rank it ahead of the CVE record and any tracker downstream of it. For a multi-branch product the CVE record is the least reliable of the three, and this incident shows what that costs.
2. Get a fix indicator that is not the version string. A file hash, a build identifier, a configuration flag, or an observed behavior change. When the vendor ships fast, the version number is the first thing to go. PaperCut's build numbers did the job here, and the vendor published them on the fifth day.
3. Treat every host exposed during the window as open until someone has looked. A patched host is not a cleared one. Rank the investigation by what ran: hosts where the service executed at high privilege with internet reach come first, and hosts where it sat idle become removal candidates.

Closing

By September 15, the cvelistV5 tree held 57,032 published records with 2026 identifiers, against 43,480 for all of 2025 and 38,454 for 2024. The share carrying at least one cvelint finding did not move with the volume: 91.1% in 2024, 91.2% in 2025, and 89.8% so far in 2026. Scores arrive late, or in two incompatible versions, or not at all, and the affected-product data is no cleaner at 57,000 records than it was at 38,000.

None of that makes the CVE catalog the enemy. Spektion matches against the same catalog every scanner does. The catalog is an input. The failure is treating it as the only input, then reporting a version comparison as if it were evidence.

PaperCut is the ordinary version of this. A vendor caught an active exploitation campaign, shipped a fix in hours, and wrote honestly about it afterward. The records still went out with a field no parser could read. NVD still resolved the fix one release short. The version number still stopped meaning anything for thirteen days. And a server that took every release on time could still be running a remote access service installed before the first one.

A patch report tells you what is installed. Knowing what the software did on the endpoint during the window, at what privilege, and with what exposure, is what tells you which hosts to open first. That is the job runtime exposure management exists to do.

How were these figures produced?

Three of the figures above come from runs a reader can repeat. The CVE window table queries the NVD API 2.0 for records published August 28 to September 9, 2026, pulled September 15, 2026, at 3:29 p.m. CT. A record counts at 7.5 or higher on the highest CVSS score it carries, any version, any source, and the KEV column checks each record against the CISA KEV catalog, version 2026.09.14. The cvelint tables run cvelint v0.7.0 over the cves/2024, cves/2025, and cves/2026 trees of the cvelistV5 release bundle cve_2026-09-15_2000Z, with records in the REJECTED state set aside. Counts are distinct records with at least one finding per rule; a record with findings under several rules appears under each, so the rule rows exceed the total. The two PaperCut records are quoted from the repository as they stood at the September 1 commit linked above.

go install github.com/mprpic/cvelint/cmd/cvelint@v0.7.0
cvelint -format json cvelistV5/cves/2026 > cvelint_2026.json
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?pubStartDate=2026-08-28T00:00:00.000&pubEndDate=2026-09-09T23:59:59.999&resultsPerPage=2000"

References

• PaperCut, URGENT Security Advisory: PaperCut NG/MF Security Bulletin (27 Aug 2026)
• Chris Dance, PaperCut, Behind the scenes: what happened after 9:42 a.m. on Thursday (September 1, 2026)
• Huntress, PaperCut Actively Exploited: A Pre-Auth RCE Chain (August 28, 2026)
• GreyNoise, Agents Gone Wild: An AI-Orchestrated Global Campaign Against PaperCut NG/MF (September 9, 2026)
• NVD, CVE-2026-81578 and CVE-2026-82078
• CISA Known Exploited Vulnerabilities Catalog
• cvelint, a CVE v5 record validator by Martin Prpič
• CVE Project cvelistV5, 2026 records
• CVE Project cvelistV5, CVE-2026-81578 and CVE-2026-82078 as recorded at commit 4113d493 (September 1, 2026), before the September 13 correction
• FIRST, Common Vulnerability Scoring System