As long as that user can talk to the printers' device nodes (and/or the network), it needn't so far as I know.

The original "system daemon vs. user program" dichotomy offers a much broader range of interpretations than this, though, and it was more the implication of "this can and should be an evanescent program invoked by individual users, implicitly persisting little or no state between invocations" to which I sought to object.

(That said, I take another nearby commenter's point regarding the need, and existence, of a more evanescent and safer option on systems that will never see more printing than one user does two or three times a year.)

Binding to ports under 1024 traditionally requires root privileges. (These days of course that isn't quite as true as it used to be.)

Why on Earth do ordinary systems need CUPS binding to a port at all?

They don't need. Want, for listening to network printers announcing themselves. It's a very bad system, even then.

Have you ever seen a network printer announce itself by talking to a print daemon on port 631?

I’ve seen network printers announce themselves over DNS-SD/mDNS and over NetBIOS, AppleTalk, etc. All of those are a layer beneath the print daemon.

They don't. cups-browsed is a legacy component that isn't needed on ordinary systems, which outsource printer discovery to an mDNS service such as avahi.

It's common practice to open the socket to start listening on the <1024 port, then drop the root privileges and continue as a different user.

On a modern Linux system, it’s better to use the CAP_NET_BIND_SERVICE capability instead. Then you don’t need to start the process as root at all.

I believe these vulnerabilities only allow RCE as the 'lp' user (which is able to access parallel ports and USB devices that identify themselves as printers). In addition the process will be confined by MAC policies (e.g., on Fedora/Red Hat I think they're confined by cupsd_t).