A Marker Was Not Enough: How Pruva Reproduced the PaperCut RCE

The first PaperCut run produced the result everyone wants to see in a remote-code-execution investigation: a command marker. It still did not prove remote code execution.

The marker appeared only after the laboratory operator changed the target locally and restarted the service. An unauthenticated attacker had not performed either operation. Accepting the marker would have rewarded the visible result while erasing the missing causal edge.

A separate Pruva verification agent, which did not produce the exploit, evaluated the claim against the current-run evidence and rejected that interpretation. The run had found meaningful unauthenticated behavior, but not the claimed stock remote command execution. That rejection set the standard for the next experiment: every exploit-state change had to cross the application boundary, the effect had to be observable remotely, the proof had to repeat after resetting the target to its pre-attack state, and the unchanged sequence had to produce no command execution against the emergency-patched build.

The second run met those conditions. Prior evidence narrowed the next search without becoming an answer key. Its repeatable request sequence later became an input for defense testing.

Scope: this is a post-setup result, not proof of immediate reachability on a never-used installation. An authenticated administrator opened PaperCut’s configuration editor once before the attacker sequence began.

What is new in this evidence

PaperCut disclosed the incident, the affected product families, emergency updates, and several investigation indicators. Pruva’s work began from that public record.

Pruva adds four runtime results:

1. A command marker from the first run was rejected because the remote attacker did not own every causal step.
2. A later run demonstrated post-setup unauthenticated command execution under the PaperCut service identity using application requests alone.
3. The proof succeeded twice after resetting the target, while the unchanged sequence produced no command execution on the tested emergency-patched build and a benign control remained functional.
4. The accepted evidence validated two retrospective application-log hunts against attack, patched-block, and benign-control samples.

From incident clues to a valid proof

In its 27 August urgent advisory, PaperCut reported active exploitation and confirmed customer incidents affecting PaperCut NG and MF. The company advised operators to restrict Application Server access to trusted addresses and published emergency patches for current release lines.

The bulletin also gave defenders several concrete investigation clues:

• suspicious post-exploitation activity from the PaperCut Application Server process;
• missing, truncated, or deleted server.log files;
• a failed JDBC-driver lookup using jdbc:no:x at the database-driver layer; and
• Card/ID lookup errors containing VALUES CAST.

PaperCut warned that absence of those indicators does not establish that a host is clean. Its patch FAQ also disclosed that patched builds restrict external Card/ID lookup SQL containing EXEC, EXECUTE, or CALL. PaperCut’s Card/ID feature maps physical card identifiers to user records; administrators can configure its external lookup behavior.

Those facts established urgency, a product surface, and useful runtime observations. They did not provide a complete causal chain that could simply be copied into a test.

The first hypothesis was useful and too certain

The initial test plan preserved the literal log signatures, identified the pre-authentication Card/ID flow as a surface worth exercising, located official installers, selected adjacent vulnerable and controlled builds, and called for inspection of the Java artifacts shipped with the product.

That preparation removed basic setup discovery from the first experiment.

The plan also promoted an inferred mechanism into the claim too early. Sparse incident clues became a detailed theory of how the application might reach code execution. The mechanism was still uncertain, but the detail made the path look settled.

That distinction matters for autonomous security research. A detailed hypothesis gives the agent useful search direction, but it also makes any nearby marker look like confirmation. The first run was the experiment that separated those two things.

A real marker on the wrong side of the boundary

The initial run crossed an unauthenticated application boundary and demonstrated security-relevant control inside PaperCut. It also reached a command marker. The marker itself was real.

The causal claim was not.

The shortest route from application control to command execution required the laboratory operator to enable a non-default capability from inside the target and restart PaperCut. Those were operator actions, not remote attacker actions. A file containing command output could not repair that threat-model gap.

This is reward hacking in reproduction work: optimizing for an easy terminal signal while bypassing the causal conditions of the security claim. The marker was easy to score; the security claim still depended on ownership, reachability, and preconditions. The same separate verification agent scored the chain.

The second experiment made success harder to fake

The next experiment reused the known-good laboratory baseline, the reachable public surface, and the paths already disproven by runtime evidence. It did not receive a working exploit. Instead, it added strict proof conditions:

• ordinary product setup and every non-attacker precondition had to be recorded;
• every exploit-state mutation had to originate from unauthenticated application requests;
• local file copies, service commands, feature toggles, and target restarts were forbidden during the attacker sequence;
• command output had to return through the application boundary under the PaperCut service identity;
• the full proof had to succeed twice after resetting the target to its pre-attack state; and
• the exact same request sequence had to produce no command artifact on the emergency-patched build while a benign control still exercised the relevant feature.

Dead ends were preserved as evidence. That kept the second experiment from repeating branches whose runtime receipts were already available.

Good pre-research removes repeated setup work and known-invalid branches. It should not replace an open experiment with an answer key.

Where the reasoning changed

The decisive progress did not come from trying the same payload more times. It came from changing what counted as evidence. The sequence below is ordered by reasoning milestone, not by elapsed time or spend.

Accepted runtime evidence

The second run used official PaperCut NG installers for the exact tested versions and builds. After ordinary setup, an authenticated administrator opened PaperCut’s configuration editor once. The attacker sequence began only after that observed setup event. From that point onward, every security-relevant state change came through new, unauthenticated remote application requests.

At the vulnerability-class level, the accepted chain combined an authorization failure with unsafe server-side interpretation. The first let an unauthenticated client influence application state reserved for a privileged workflow. Stock application behavior later consumed that state under the PaperCut service identity. This supplied the remote causal edge that the first experiment lacked.

The result reached operating-system command execution as the PaperCut service account. The output was retrieved over HTTP through the target application, rather than inferred from a file inspected inside the container. The complete script succeeded twice from fresh state.

Six causal edges in the accepted chain

The accepted chain contains six causal edges. Each one was established by runtime evidence rather than inferred from the final command marker.

The important result is the composition, not any one object in it. The first run had reached the last visible effect only after local operator intervention. The accepted run connected all six edges with remote application evidence, then reproduced the same sequence from another clean reset.

The remote receipt

The accepted evidence is more concrete than a success flag. The remote client received command output containing the effective service identity from both vulnerable replays. The normalized receipt retains the HTTP status, service identity, and control outcome:

The proof client retrieved the receipt over the application network boundary. The attacker sequence contained no Docker file copy, no target-side command, no feature enablement, and no service restart. Before the second successful replay, the target was reset to its pre-attack product state.

The build identity was equally controlled. Both targets came from official Linux installers: PaperCut NG 25.0.11 build 75758 for the vulnerable target and 25.0.12 build 76497 for the emergency control. No product binaries were patched to create the result.

The unchanged request sequence was then replayed against PaperCut NG 25.0.12. It produced no command-execution effect: no command artifact appeared and the remote receipt was absent. A benign control still reached the configured product feature. That last observation matters because a disabled feature is not a precise fixed-version control.

The evidence supports a deliberately bounded statement:

Learning and return on spend

The second experiment did not start from zero. It preserved installer identities, known-good setup steps, the reachable Card/ID surface, and branches already disproven by runtime evidence. Every inherited fact still had to be revalidated.

That transfer changed where the next run spent its search. It no longer paid to rediscover the laboratory or repeat dead ends; it could concentrate on the causal edge missing from the first proof.

The economics reflect that transfer. The first Kimi K3 investigation cost USD 48.75 and returned useful primitives plus an invalid command-execution claim. The second cost USD 27.17 and returned the accepted remote proof, two clean repeats, the fixed-build control, and bounded follow-up analysis. These are provider-accounted totals grouped by the role that incurred them: primary investigation, follow-up analysis, separate verification, and setup or evidence processing.

Both investigations used Kimi K3, so the comparison is between experimental designs rather than models.

From exploit proof to a defense package

A security report can describe what happened. A deterministic reproduction can ask whether a defense observes or prevents the same behavior.

The accepted script therefore provides a repeatable attack input for defense work.

The first validated hunting layer starts with PaperCut’s published indicators. Two narrow application-log hunts were replayed against preserved evidence:

• a Card/ID lookup hunt matched four attack events in the vulnerable replay; and
• a patched-runtime rejection hunt matched two blocked attempts in the controlled replay.

Neither hunt matched the benign fixed-build Card/ID control. That is useful retrospective coverage. It does not imply that any endpoint or network prevention control has been validated.

Validated now: application-log hunts

The two application-log rules start from PaperCut’s published indicators and observable log behavior. Sigma is a portable detection-rule format; these rules express the required application message fields without embedding the exploit request. Across the preserved corpus, the first rule matched all four labeled vulnerable query events and the second matched both labeled patched-runtime block events. Neither matched the benign fixed-build control. An ordinary card lookup, a VALUES/CAST string without the Card/ID error prefix, and an exception-only block line also remained quiet.

They remain experimental Sigma rules. PaperCut server.log is not a universally standardized Sigma source, so each deployment must map its raw message field to message and confirm that log multiline handling does not split the indicator.

title: PaperCut Suspicious External Card Lookup Query Material
id: a7d75aae-9bd5-4c0d-96e0-e66c9ebc40fd
status: experimental
logsource:
  category: application
  product: papercut
detection:
  selection_lookup:
    message|contains: 'Database error looking up cardID:'
  selection_query_value:
    message|contains:
      - 'VALUES(CAST('
      - 'VALUES CAST('
  condition: selection_lookup and selection_query_value
falsepositives:
  - Authorized testing of a custom external Card/ID lookup integration
level: high
tags:
  - attack.initial-access
  - attack.t1190

title: PaperCut Blocked Unsafe External User Lookup SQL
id: f0de3dd2-c0ae-43ec-a5ea-9b3717e56dc8
status: experimental
logsource:
  category: application
  product: papercut
detection:
  selection_lookup:
    message|contains: 'Error occurred looking up external user with card:'
  selection_block:
    message|contains: 'Unsafe external user lookup SQL blocked'
  condition: selection_lookup and selection_block
falsepositives:
  - Administrator testing a legacy external Card/ID lookup configuration after patching
level: high
tags:
  - attack.initial-access
  - attack.t1190

For collectors that ingest server.log as raw text, the ordered-text validation used these extended regular expressions. They are separate raw-log tests, not one-to-one translations of Sigma’s field conditions:

Query-shaped Card/ID lookup

Database error looking up cardID:.*VALUES[ (]+CAST\(

Patched unsafe-lookup block

Error occurred looking up external user with card:.*Unsafe external user lookup SQL blocked

The laboratory’s benign card value is not a production exclusion. It proves the frozen test corpus stayed quiet; converting one test value into a global suppression would create an avoidable blind spot. Adapt regex syntax to the target SIEM and retain the complete raw event for investigation.

What defenders should do now

The research result does not supersede PaperCut’s guidance. Operators should restrict Application Server access to trusted addresses, apply the vendor’s current emergency update, and investigate exposed systems rather than waiting for a public reproduction.

Preserve Application Server logs and investigate unexpected PaperCut child processes, the exact Card/ID and JDBC errors listed in the bulletin, and missing or truncated logs. A blocked response or absence of one published indicator does not prove that no side effect occurred; correlate application, process, filesystem, and network evidence.

The larger lesson is not specific to PaperCut. A marker is evidence of an effect. It is not evidence that the claimed attacker caused that effect through the claimed path. The first run became useful only when we preserved what it genuinely proved, rejected what it did not, and made the next experiment harder to fool.