How do you run an emergency change on a utility app that was never scored as critical?

Trigger the emergency change on the KEV clock and the exposure, not the app's original criticality label. Contain first with an interim compensating control such as IP allow-listing, patch to the fixed build within the deadline, verify the build number and that authentication is enforced, then run a post-implementation review that corrects the criticality score that missed the asset. PaperCut NG/MF is the current worked example: CISA gave it a September 14 deadline.

Print Server Emergency Change: When a Utility App Turns Critical

Q: How do I verify the emergency change succeeded?

Confirm the running build number matches the fixed build in the bulletin, re-test that authentication is enforced on the previously exposed function, and decide whether the interim containment can be safely removed. Attach that evidence to the change record before closing it.

This is operational change-management guidance for defenders and change managers, not legal, compliance, or security-testing advice. It contains no exploitation detail. Product versions and mitigations are named to help you scope a change, and every vendor mention notes at least one limitation. Some outbound links may be affiliate links.

Why this matters

Most change-management programs are built around the systems everyone agrees are important: the ERP, the domain controllers, the payment stack. The assets that actually generate emergency changes are frequently the ones nobody bothered to tier — the print server, the badge-reader controller, the meeting-room scheduler. They were installed years ago, scored as low-impact because “it just prints,” and then quietly connected to the internet or left reachable from the user VLAN.

On August 31, 2026, CISA added two PaperCut NG/MF vulnerabilities to the Known Exploited Vulnerabilities catalog: CVE-2026-81578, a missing-authentication flaw that lets an unauthenticated remote attacker modify system configuration, and CVE-2026-82078, an unsafe-reflection flaw that can lead to arbitrary Java bytecode execution (NVD CVE-2026-81578). Both carry a federal remediation deadline of September 14, and both required action references CISA’s BOD 26-04, Prioritizing Security Updates Based on Risk. A print-management server just landed on a 14-day clock. This piece is the repeatable pattern for handling that, using PaperCut as the live example.

The trigger is the clock and the exposure, not the label

The mistake that stalls these changes is arguing about the asset’s criticality tier while the deadline runs. That debate is the wrong one. A missing-authentication vulnerability on an internet-reachable service does not become less urgent because the service prints payslips instead of processing them. The emergency-change trigger should be defined by two facts you can establish in minutes: is the affected product on the KEV catalog with an active deadline, and is an affected instance exposed beyond its intended trust boundary. If both are true, the change is an emergency regardless of how the asset was scored last year.

This is the same logic we built into the BOD 26-04 emergency-change decision matrix: the directive’s risk-based deadlines give you a defensible, pre-agreed trigger so the change-advisory board is not relitigating urgency under time pressure. For a utility app, the exposure question is the one that most often gets answered wrong, because teams assume a “boring” system is not reachable. Confirm it rather than assume it, using whichever of the asset-exposure discovery approaches your shop already runs.

Phase 1: contain before you patch

The first move is not the patch. Emergency patches take time to schedule, test, and apply, and the deadline is a maximum, not a target. The immediate step is to reduce exposure so the clock is less dangerous while you work.

For PaperCut specifically, the vendor documents an IP allow-list for the admin interface: under Options then Advanced, the “Allowed admin IP addresses” field accepts a comma-separated list of addresses or subnets and writes the configuration key auth.admin.allowed-addresses (PaperCut restrict-access guide). Restricting administrative and device access to known management subnets, and pulling the server off any public interface, shrinks the attack surface immediately. The general principle is vendor-agnostic: constrain who can reach the vulnerable function while the patch is prepared.

Whatever interim step you take, record it as a compensating control in the change ticket, not as an informal firewall tweak someone will forget. That record matters for the audit trail and for Phase 3, when you decide whether it is safe to remove. If you keep a formal register, log it there the same way you would any other deferral control, following the entry format in the compensating controls register piece. One caveat: IP allow-listing is a containment measure, not a fix. It reduces exposure but does not remove the vulnerability, and it can be bypassed if an attacker already has a foothold inside the allowed range, so it does not reset the deadline.

Phase 2: patch to the named build

With exposure contained, apply the fix within the deadline. Precision on version numbers is what keeps this change from failing verification later.

PaperCut’s security bulletin of August 27, 2026 states the advisory applies to all versions of PaperCut NG and MF, and provides Emergency Patch Release 3 for the supported major versions — v24, v25, and v26 — with Release 3 superseding and including all prior emergency patches. The bulletin lists specific build numbers per version and platform (for example, the v26 builds are numbered 76531, with v25 and v24 on their own build numbers), so the change ticket should name the exact target build, not just “latest.” Instances running v23 or earlier are not given an emergency patch and must be upgraded to a supported release, which is a larger change with its own testing and rollback plan.

The change record should cite the KEV CVE identifiers and the September 14 deadline explicitly. That citation is what converts an urgent request into a documented, risk-based decision an auditor or the CAB can review afterward. NIST’s SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, frames exactly this: patching is preventive maintenance that should be planned around risk-based prioritization and defined maintenance windows, including expedited paths for high-risk cases, rather than handled ad hoc each time.

Phase 3: verify the fix actually took

An emergency change is not closed when the installer finishes. Verify three things. First, confirm the running build number matches the fixed build from the bulletin — a half-applied upgrade or a rolled-back service is a common failure mode under time pressure. Second, re-test that authentication is enforced on the previously exposed function, since the point of the fix is that the missing-authentication path is closed. Third, decide whether the interim containment from Phase 1 can be safely removed, and only remove it if the patch is confirmed and monitoring is in place; there is rarely harm in leaving a tightened IP allow-list on a management interface.

Attach the evidence — build number, a screenshot or log of the enforced authentication check, and the containment decision — to the change record. This is the closure artifact. Skipping it is how a server shows up as “patched” in the change system while still running the vulnerable build in production.

Phase 4: the post-implementation review that fixes the scoring

The most valuable phase is the one teams skip. A post-implementation review (PIR) on an emergency change is standard ITIL practice, but for a utility-app emergency it has a specific job: find out why the asset was scored low enough to be invisible to your change process, and fix that score. NIST’s incident-handling guidance makes the same point in a security context, treating the lessons-learned step as a required part of closing out an event rather than an optional retrospective (NIST SP 800-61).

The scoring error is usually a category mistake. Criticality was assessed on business function (“it just prints”) instead of on the security categorization that FIPS 199 describes — the potential impact on confidentiality, integrity, and availability if the system is compromised (FIPS 199). A print server processing payslips and reachable from the internet is not low-impact under that lens. The PIR output should be a corrected criticality score and, ideally, the addition of the whole asset class — utility appliances with management interfaces — to your standing emergency-change authorization, so the next one triggers automatically instead of requiring this same scramble.

What to do about it

If you run PaperCut or any similar utility appliance, here is the sequence in order:

Establish the two trigger facts. Confirm the product is on the KEV catalog with an active deadline and that an affected instance is exposed beyond its intended trust boundary. If both hold, declare the emergency change.
Contain first. Apply an interim compensating control — for PaperCut, the admin IP allow-list via auth.admin.allowed-addresses — and pull the server off any public interface. Record the control in the change ticket.
Patch to the named build. Apply the vendor’s fixed build (PaperCut Emergency Patch Release 3 for v24/v25/v26; upgrade for v23 and earlier), citing the CVE IDs and the September 14 deadline in the record.
Verify. Confirm the running build number, re-test that authentication is enforced, and attach the evidence before closing.
Run the PIR. Correct the criticality score that missed the asset, and add the asset class to your standing emergency-change authorization so it triggers automatically next time.

Frequently asked questions

Why treat a print server as an emergency change at all? Because the trigger is the KEV deadline and the exposure, not the app’s business function. A missing-authentication flaw on an internet-reachable service carries the same urgency regardless of what the server does, and PaperCut NG/MF received a September 14 federal remediation deadline under BOD 26-04.

What is the interim mitigation for the PaperCut vulnerabilities? PaperCut documents restricting admin access by IP under Options then Advanced, which writes the auth.admin.allowed-addresses key; pulling the server off public interfaces reduces exposure while you patch. It is containment, not a fix, and does not reset the deadline.

Which PaperCut versions are affected and what is the fix? The August 27, 2026 bulletin states all versions of PaperCut NG and MF are affected. Emergency Patch Release 3 is provided for v24, v25, and v26 with specific per-platform build numbers, while v23 and earlier must be upgraded to a supported release.

How do I verify the emergency change succeeded? Confirm the running build number matches the fixed build, re-test that authentication is enforced on the previously exposed function, and decide whether the interim containment can be safely removed — then attach that evidence to the change record before closing it.

What should the post-implementation review cover? It should find why the asset was scored low enough to be invisible to your change process and correct that score using a security-impact lens such as FIPS 199, then add the asset class to your standing emergency-change authorization.

This piece is part of our change management coverage. To pressure-test whether a change like this warrants your emergency track, run the inputs through the change risk score tool.

Sources

#emergency-change #cisa-kev #papercut #change-management #compensating-controls

Published September 7, 2026.