Missing Authorization Affecting yeswiki/yeswiki package, versions >=4.6.2, <4.7.0

Affected versions of this package are vulnerable to Missing Authorization via ActivityPubService::syncActorPosts in tools/bazar/services/ActivityPubService.php, which processes remote ActivityPub activities (Create, Update, Delete) and performs garbage collection of mirrored entries without any per-activity authorization checks. The parallel inbox handler processActivity enforces assertOwns() and sameHost() on every mutation, but the sync handler reaches the same EntryManager::delete, update, and create sinks with no equivalent guards. A malicious ActivityPub server operator can cause a YesWiki administrator (a confused deputy) to delete, overwrite, forge, or mass-delete wiki entries belonging to other federated actors by returning a poisoned outbox during a routine sync operation. The garbage-collection loop additionally deletes all local entries whose sourceUrl host matches the attacker's actor host but are absent from the attacker's outbox, enabling mass collateral deletion across a shared hosting domain.

Note: This is only exploitable when ActivityPub is enabled on at least one Bazar form and at least one mirrored entry from a third-party federated actor exists, and requires an administrator to initiate a sync with the attacker's actor (or be induced to do so via a CSRF link, since the sync action uses GET with no CSRF token).

Administrators can reduce exposure by avoiding syncing with untrusted remote ActivityPub actors. Adding a CSRF token requirement to the sync action would prevent the cross-site request forgery amplification vector, but does not address the core missing authorization issue.

Prerequisites: A YesWiki instance with ActivityPub enabled on at least one Bazar form,
with at least one mirrored entry from a third-party federated actor.

The attacker operates a server that returns the following actor document and outbox:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://evil.example/actors/attacker",
  "type": "Person",
  "outbox": "https://evil.example/actors/attacker/outbox",
  "publicKey": { "id": "https://evil.example/actors/attacker#main-key", "publicKeyPem": "..." }
}

The outbox contains a Delete activity targeting a third-party entry:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "OrderedCollection",
  "orderedItems": [
    {
      "type": "Delete",
      "object": "https://innocent.example/entries/42"
    }
  ]
}

When an admin syncs with the attacker's actor via ?vue=abonnements&action=sync&idformulaire={id}&actor=https://evil.example/actors/attacker, the entry mirrored from https://innocent.example/entries/42 is deleted without authorization.

Expected result: sync rejects cross-actor Delete (as processActivity does via assertOwns)
Actual result: entry is deleted unconditionally ($forceEvenIfNotOwner=true)

Note: The PoC states prerequisites of a YesWiki instance with ActivityPub enabled on at least one Bazar form and at least one mirrored entry from a third-party federated actor, but names no specific version, operating system, or runtime.

• GitHub Advisory