Summary

A normal authenticated member can overwrite an existing tenant blob, including the tenant logo, by creating a post attachment whose bkey is set to an already existing tenant blob key. Because the attachment upload path accepts a client-controlled bkey and the storage layer overwrites content for an existing key, a low-privileged member can replace a shared trusted asset such as the tenant logo.

Details

During testing of getfider/fider on commit 446bce9802d82b53b439748b390e9af81eb91491, I found that attachment uploads trust a client-supplied blob key.

Relevant behavior:

• ImageUpload exposes bkey directly:

  type ImageUpload struct {
      BlobKey string `json:"bkey"`
      Upload  *ImageUploadData `json:"upload"`
      Remove  bool `json:"remove"`
  }

• Member-accessible post creation uploads images before attachment association:
  • POST /api/v1/posts
  • POST /api/v1/posts/:number/comments
• The post creation path calls:
  • cmd.UploadImages{Images: action.Attachments, Folder: "attachments"}
  • then cmd.SetAttachments{Attachments: action.Attachments}
• Tenant settings use blob-backed logos, and the tenant object exposes logoBlobKey.

In practice, a normal authenticated member can:

1. learn the current tenant.logoBlobKey
2. submit a normal post attachment upload
3. set attachments[0].bkey to the tenant logo blob key
4. upload attacker-controlled image content
5. cause the existing tenant logo blob content to be replaced

This is an object-level authorization/integrity issue: an unprivileged member can overwrite an existing privileged shared blob by reusing its key.

PoC

Tested locally on commit:
446bce9802d82b53b439748b390e9af81eb91491

Reproduction steps:

1. Start Fider locally.
2. Create the first tenant and verify the admin email.
3. Create a low-privileged member account.
4. Sign in as the member.
5. As admin, upload a tenant logo image.
6. Read the tenant logo blob key (logoBlobKey).
7. As the member, create a new post and send an attachment object where:

• attachments[0].bkey = tenant.logoBlobKey
• attachments[0].upload contains attacker-controlled image bytes

8. Observe the request succeeds with HTTP 200.
9. Fetch the original logo URL before and after the member request.
10. Compare hashes and confirm the logo content changed.
11. Confirm the attachments table stores the forged attachment_bkey equal to the tenant logo blob key.
    Observed proof from my reproduction:

• low-privileged member role: visitor
• forged member request returned 200 OK
• attachments.attachment_bkey matched the tenant logo_bkey
• the logo content hash changed after the member request

Example impact demonstrated:

• tenant logo was overwritten by a normal authenticated member

Impact

A normal authenticated member can overwrite the tenant logo and potentially other tenant blobs if their keys are known. This enables:

• tenant branding defacement
• phishing / trust abuse within the application
• unauthorized modification of shared tenant assets

This appears to be an object-level authorization and integrity failure caused by trusting a client-controlled blob key for uploads and allowing reuse/overwrite of an existing key.

Suggested remediation

• Ignore client-supplied bkey for new uploads and always generate a fresh server-side blob key.
• Prevent overwrite of existing blob keys unless explicitly authorized.
• Bind blobs to purpose/ownership and reject cross-purpose reuse.
• Restrict attachment uploads to attachment-specific namespace only.

Attachment

report_fider_blob_overwrite.zip