The PaperCut zero-days showed why office systems need an owner

Print-management software can sit outside the list of systems a business normally discusses when it talks about security. It still has users, a server, network connections, and access that need an owner.

What happened in August

On August 27, PaperCut published an urgent advisory about active exploitation affecting PaperCut NG and MF. Its response included restrictions on access to internet-facing Application Servers and several emergency patch releases. The vendor later published maintenance releases that superseded those emergency patches. Read the advisory and its update history.

The bulletin also described unexpected remote-access software as a possible sign of post-compromise activity and warned that the absence of listed indicators did not establish that a server was unaffected. A later September security bulletin provides additional product-specific guidance. Use the current vendor guidance for your exact product and version.

Put the office systems on the same list

My recommendation is to include print management, scanners, building systems, backup consoles, and other shared office services in the regular asset review. Record the product, version, host, owner, support provider, and the business process that depends on it.

For each service, establish who can approve an update and who can perform it. A print vendor may manage the application while an IT provider manages the server. Make that division explicit so an urgent advisory reaches the person who can act.

Review how the management interface is reached

Find the administrative interface and document the actual path to it. Ask why each external connection is required. Use the product's current hardening guidance and have the system owner verify the resulting access limits.

Check the accounts and integrations as well as the interface. A service that supports printing might also connect to a directory or a database. Give each connection only the access required for its job, and include its credentials in the recovery plan.

An update is one part of the response

If the service was exposed during an active attack campaign, preserve the evidence needed for investigation and establish whether unauthorized activity occurred. Follow the vendor's incident guidance and involve the incident lead when compromise is suspected.

Verify the installed build across every relevant server, then check that ordinary business workflows still work. Keep a record of the versions, the verification date, and any follow-up required. A download or a successful installer message does not answer every deployment question.

Give recovery a practical rehearsal

Know where a clean backup is stored and what restoring it requires. Include configuration, licenses, connected services, and the credentials needed to rebuild. Test the process in a safe environment when possible.

The lesson for a small team is straightforward: a system can be easy to overlook and still have valuable access. Give it an owner, a supported version, a controlled management path, and a recovery process before the next urgent notice arrives.