Verification picks by signedPropertyNames without checking the record against it, so a record can skip crosspost recursion

[Rinse12]

Verification picks the record down to signature.signedPropertyNames before checking anything. A field present in the bytes but absent from that list is dropped and never inspected, while remaining in what gets stored and rendered. signedPropertyNames lives inside signature, which is not part of the signed bytes, so the list is chosen by whoever signs the record.

So what gets verified is a strict subset of what clients display, and the record chooses the subset.

The concrete exploit today: crosspost

Leave crosspost out of signedPropertyNames on a record that has one. pick() drops it, so _verifyCrosspost is never called for that level. The nested embedded record then gets no cid check, no signature check and no reserved-field check, while still being present in the bytes, persisted to the db, and available for a client to render by walking comment.crosspost.comment.crosspost.comment.

The outer record's own cid stays consistent, since it hashes the whole record either way, so check 1 of tier 1 passes.

This is the sharp case because crosspost is the only field whose presence in the picked object triggers verification of a subtree signed by a different key. Every other field is one the attacker already controls.

Two ways such a record reaches a client:

• an embedded crosspost.comment (feat(crosspost): embed the reposted comment in comment.crosspost (#32) #248), verified inline by _verifyCrosspost
• a cid the client did not get from a community-signed page or CommentUpdate, passed to createComment({ cid }) / getComment({ cid })

Why the other fields are not exploits

Worth writing down, since it is the first place this investigation went wrong.

Shrinking signedPropertyNames on someone else's genuine record changes the encoded bytes, so their signature stops verifying. The attacker therefore always signs with a key they control, which means they can set every field value anyway. Leaving a field unsigned changes accountability, not capability.

• content / title / link — the attacker authored them either way. The only delta is repudiation.
• author — impersonation via author.name is not gated by the signature even when author is signed. It is gated by name resolution, which runs in the background and sets nameResolved (src/clients/base-client-manager.ts, src/publications/comment/comment.ts), outside verification entirely. Note author.address is runtime-only, derived as name || publicKey, and is in AuthorReservedFields, so it is never on the wire. See docs/protocol/wire-vs-runtime.md.
• communityName / communityPublicKey — still just an author claim, resolved at tier 2 either way.

The general hazard is forward-looking: any field added later whose verification is gated on it being present will inherit the crosspost bypass unless this is fixed.

Mechanism

_verifyJsonSignature (src/signer/signatures.ts) rebuilds the signed object by reading signedPropertyNames off the record itself. JsonSignatureSchema types it as z.string().array() with no refinement pinning it to CommentSignedPropertyNames.

The check that closes this is _allFieldsOfRecordInSignedPropertyNames, and it only helps when it runs on the un-picked record:

• Community acceptance: covered. respondWithErrorIfSignatureOfPublicationIsInvalid passes request.comment un-picked, so the guard fires (ERR_COMMENT_PUBSUB_RECORD_INCLUDES_FIELD_NOT_IN_SIGNED_PROPERTY_NAMES). An honest community never mints a cid for such a record.
• Client verification: not covered. verifyCommentIpfs and _verifyCrosspost both pick(record, ["signature", ...signedPropertyNames]) before delegating, because a legitimate CommentIpfs carries community-generated fields (depth, thumbnailUrl*, previousCid, pseudonymityMode) that no author signs. After the pick the guard can never fail.

On the normal load path the cid's provenance substitutes for the guard, since the cid came from a community-signed page or CommentUpdate and the community ran the guard. For an embedded crosspost record there is no substitute, because tier 1 is offline by design.

Candidate fix

A targeted guard on both picking paths, over the signable set only:

for (const name of CommentSignedPropertyNames)
    if (record[name] != null && !record.signature.signedPropertyNames.includes(name))
        return { valid: false, reason: messages.ERR_... };

Targeted rather than a blanket allowlist: every read site uses CommentIpfsSchema.loose() and backward.compatibility.comment.test.ts pins that unknown extra props survive a load, so a future protocol version can add fields without old clients rejecting records. Restricting the rule to CommentSignedPropertyNames keeps that intact.

Safe for old records, since it only fires when a signable field is present and unsigned. A record predating a field does not carry it. Author-signed extra props already land in signedPropertyNames.

A UI warning is not a substitute for the crosspost case specifically: the library never recursed, so there is no signal for a client to surface without reimplementing _verifyCrosspost.

Open questions

1. Fix just the crosspost bypass in _verifyCrosspost, or the general subset problem on every picking path?
2. Reject, or expose a signal? Rejecting is a client-visible behavior change.
3. Apply to Vote / CommentEdit / CommunityEdit too?
4. Constrain signedPropertyNames at the schema level instead, so a list that is not a subset of the canonical set fails parsing? Broader wire-format decision.

Refs

• feat(crosspost): embed the reposted comment in comment.crosspost (#32) #248, and the CodeRabbit review comment on src/signer/signatures.ts that started this
• signedPropertyNames only signs top-level keys — limits extensibility and selective signing #87 (closed) for the related but distinct limitation that signedPropertyNames only covers top-level keys

[Rinse12]

Update: the crosspost instance of this is fixed in #248.

_verifyCrosspost now has a check 4 that verifies crosspost.comment.crosspost off the raw record rather than the picked one, so checks 1 to 3 apply at every level regardless of what the level above signed. Guarded on the signed case having already descended, otherwise a chain gets walked twice per level. Regression tests in test/node-and-browser/crosspost/verification.test.ts, under "a record cannot skip its own subtree by leaving crosspost out of signedPropertyNames".

Two corrections to the description above while implementing it:

No modified client is needed. _signJson derives signedPropertyNames from keys(pick(publication, names)), and remeda's pick omits absent keys. So a post signed with no crosspost simply has no crosspost entry in the list. Attaching a crosspost to the record afterwards leaves the signature valid. Stock client, two lines.

The impact was narrower than written. The attacker can already put arbitrary content and an arbitrary author.name in a nested record on the fully verified path, by signing it with a throwaway keypair — nameResolved never runs on embedded records, so the signature was not buying attribution there. What the bypass uniquely bought was the two skipped checks: reserved/runtime fields on the nested record, and a nested crosspost.cid that lies about its own bytes, which lets a tier-2 fetch attach a genuine community-signed CommentUpdate to content that community never saw.

What remains open here. The same picking problem at the top level: verifyCommentIpfs picks by the record's own signedPropertyNames, so a CommentIpfs carrying an unsigned crosspost skips _verifyCrosspost entirely. Community acceptance catches that (the guard runs on the un-picked record), so it only reaches a client verifying a cid it did not get from a community-signed page or CommentUpdate. The candidate fix in the description still applies.

[Rinse12]

The append case, which the "Why the other fields are not exploits" section does not cover

That section argues content / title / link are not exploitable because "shrinking signedPropertyNames on someone else's genuine record changes the encoded bytes, so their signature stops verifying. The attacker therefore always signs with a key they control."

That is correct for removing an entry from the list. It does not cover adding a field the list never had, which needs no edit to signedPropertyNames at all.

Alice publishes a link post: {title, link, author, communityName, timestamp}. She wrote no content, so _signJson derives a signedPropertyNames with no content entry. An attacker takes her record verbatim, appends content: "...", recomputes crosspost.cid over the new bytes, and crossposts it.

• signedPropertyNames is untouched, so _verifyJsonSignature reconstructs exactly Alice's original fields and her signature verifies.
• Check 1 passes: the cid hashes whatever bytes are present.
• Checks 2, 3 and 4 pass.
• nameResolved comes back true, because Alice really did sign it.

The attacker's text renders as Alice's, under Alice's resolved domain. Same move for appending link: to a text post. Link-only and title-only posts are the common case, so the precondition is not exotic.

Why this is crosspost-specific rather than general

A top-level publication is protected: respondWithErrorIfSignatureOfPublicationIsInvalid passes the un-picked record, _allFieldsOfRecordInSignedPropertyNames fires, and an honest community rejects it with ERR_COMMENT_PUBSUB_RECORD_INCLUDES_FIELD_NOT_IN_SIGNED_PROPERTY_NAMES. _verifyCrosspost picks before delegating, so that guard is dead for an embedded record. An embedded record therefore has strictly weaker guarantees than the same bytes submitted at top level.

Tier 2 does catch it, but that argument proves too much

The forged cid was never minted by the referenced community, so no CommentUpdate resolves and tier 2 fails closed. The same is true of a lying cid (check 1), a broken signature (check 2), reserved fields (check 3) and an unsigned nested chain (check 4). If "tier 2 catches it" settled the question, none of tier 1 would need to exist.

Three reasons it does not settle it here:

1. Tier 2's failure mode is indistinguishable from the benign case the feature exists for. The stated reason for embedding rather than linking is that the copy survives the original community disappearing. So "no CommentUpdate resolved" is the expected steady state for a legitimate crosspost of a dead, slow or offline community. A client cannot read absence as forgery without breaking the headline use case.
2. Tier 2 is opt-in and unhelpered by design. No helper in pkc-js; the client hand-rolls createComment({cid, raw}) + update() per embedded record, per chain level. Tier 1 is the default render path.
3. This is the one place the library emits a positive signal at tier 1. _resolveAuthorNamesInBackground resolves the level-1 embedded author automatically, so crosspost.comment.author.nameResolved === true arrives with no fetch of the embedded cid. docs/protocol/crossposts.md reads that as "the name's TXT record points at the key that signed the embedded record". Under the append case Alice signed only part of the record, so the client gets an affirmative identity verdict rendered next to text she never wrote. Contrast thumbnailUrl, where the doc at least says do not render it at tier 1.

Consequences for the fix

The candidate fix in the issue body already closes this unchanged:

for (const name of CommentSignedPropertyNames)
    if (record[name] != null && !record.signature.signedPropertyNames.includes(name))
        return { valid: false, reason: messages.ERR_... };

Only the severity argument changes. Recording it here so the issue does not get closed on the reasoning in "Why the other fields are not exploits", which is sound only for the removal case.

While this stays open, two doc statements in docs/protocol/crossposts.md are overstated: tier 1 "proves who wrote the content", and the nameResolved: true row. The client-rules list also has no entry for content / title / link.