Joseph Chiarchiaro

Who I am

A tinkerer who never outgrew taking things apart to find out how they work.

Twenty-odd years in enterprise IT, most of it spent in the plumbing: identity, directories, messaging. The systems everything else quietly depends on, that nobody thinks about until they break. I spent those years being one of the people who got called when they broke.

Slight ADHD perfectionist, so I’ll chase a loose thread far longer than is reasonable and I genuinely cannot leave something half-understood. It’s a character flaw that occasionally produces a CVE.

Always learning, always moving, usually at an hour that suggests questionable judgement.

What I do

Independent security research, wherever something is running with more privilege than anyone has looked at recently. In practice that means reading the code, rebuilding the thing in a lab, and trying to make it do something it was never meant to do — then proving it on the wire before saying it out loud.

Print Overrun is where the MFP work lands: the devices, print and scan servers, fleet-management software, and the document workflows connecting them to the rest of an enterprise. The credentials they hold, the identities they trust, and the documents they move.

A disclosure here claims what was reproduced and nothing beyond it — where a step is plausible but was never actually executed, it says so.

Why I do it

Because I spent two decades responsible for systems like these, and I know how much rides on them. A print server authenticates people, queries the directory, stores credentials and executes code. It tends to get scoped, patched and watched as though it were a printer.

The reassuring version is simple: secure workstation, printer, paper in your hands. Or a scan that arrives in the right inbox. The parts you don’t see can include temporary files, retained jobs, device storage, service accounts, and connectors into other systems. A successful job confirms delivery. It doesn’t establish who could read, retain, redirect, or alter it along the way.

This layer can fall between teams, leaving gaps in ownership and review. The people best placed to find the problems are often the same people keeping it running — which is already a full-time job. I have the luxury of curiosity and a lab, so I go looking.

Coordinated disclosure

The vendor gets the finding privately, enough evidence to investigate, and a reasonable opportunity to fix it. I communicate a disclosure deadline, follow up, and work toward a release that gives affected users something useful: a fix, a mitigation, or a clear account of the risk. The timing reflects severity, evidence of exploitation, and progress toward remediation.

Coordination takes good faith on both sides. If a vendor does not respond, declines to address a demonstrated issue, or keeps delaying without a credible plan, I may publish after the communicated deadline even without a fix or the vendor’s agreement. I make reasonable attempts to reestablish contact, give advance notice of publication, and may seek help from CERT/CC or another coordinator. Extensions need a concrete reason; silence does not create an indefinite embargo. Active exploitation may warrant a shorter timeline.

Public warning and exploit publication are separate decisions. A disclosure can describe the affected systems, demonstrated impact, available mitigations, and coordination timeline while withholding reproduction code or other details that would put unpatched users at greater risk. Vendor disagreement and unresolved questions are identified as such. The aim is to help people protect their systems, with claims supported by evidence.

This approach is informed by the CERT Guide to Coordinated Vulnerability Disclosure.