Fix the reported security issue on v5

[ae2079]

we had this report from a user:
Hello Giveth security team,

I believe I found a service vulnerability in the Giveth frontend/backend project update flow. I did not execute this against production data. The evidence below comes from source review plus read-only public GraphQL queries.

Reporter: davethediver
Email: dave.the.diver1010@gmail.com
Ethereum address for reward distribution: 0xa882D8296CCd4eD5A4Ffe4cFaDd1bDf8DFA541D6

Summary

A project owner can store arbitrary HTML in a project update through addProjectUpdate / editProjectUpdate. If that update is selected as a featured project update, the homepage featured update card renders content with dangerouslySetInnerHTML without sanitization.

This creates a stored XSS path for visitors viewing the homepage/featured project update card. A particularly risky path is:

1. A project owner creates a benign project update.
2. Giveth admin features that project update via AdminJS.
3. The project owner later edits the same featured update to include malicious HTML/event attributes.
4. The homepage fetches the featured update and injects content directly into the DOM.

Impact

JavaScript execution in the giveth.io origin could read same-origin localStorage values, including the app's auth token storage keys, and perform authenticated GraphQL/API actions as the victim. It could also alter donation/project UI, show wallet-phishing prompts, or redirect users from the trusted Giveth origin.

Evidence

Frontend repo: Giveth/giveth-dapps-v2, local HEAD 4cb06d1

The homepage featured update card directly injects raw update HTML:

src/components/views/homepage/projectUpdatesBlock/ProjectUpdateSlide.tsx

<UpdateDesc
  dangerouslySetInnerHTML={{
    __html: update?.content || '',
  }}
/>

That content comes from the public featuredProjectUpdate(projectId) query:

src/apollo/gql/gqlProjects.ts

query featuredProjectUpdate($projectId: Int!) {
  featuredProjectUpdate(projectId: $projectId) {
    id
    title
    projectId
    userId
    content
    isMain
    createdAt
  }
}

Backend repo: Giveth/impact-graph, local HEAD 870dcbc

addProjectUpdate stores the caller-supplied content directly:

src/resolvers/projectResolver.ts

const update = ProjectUpdate.create({
  userId: user.userId,
  projectId: project.id,
  content,
  title,
  createdAt: new Date(),
  isMain: false,
});

const save = await ProjectUpdate.save(update);

editProjectUpdate lets the project owner replace content directly:

update.title = title;
update.content = content;
await update.save();

The entity stores content as a plain string column. The insert/update hook only generates a text summary; it does not sanitize the stored HTML:

src/entities/project.ts

@Field(_type => String)
@Column()
content: string;

@BeforeInsert()
setProjectUpdateContentSummary() {
  this.contentSummary = getHtmlTextSummary(this.content);
}

AdminJS selects existing update rows as featured records by projectUpdateId:

src/server/adminJs/tabs/projectsTab.ts

const featuredProject = FeaturedUpdate.create({
  projectUpdateId: update.id,
  projectId: update.project!.id,
});

await featuredProject.save();

The backend query returns the referenced update row:

src/resolvers/projectResolver.ts

const featuredProject = await FeaturedUpdate.createQueryBuilder(
  'featuredProject',
)
  .innerJoinAndSelect('featuredProject.projectUpdate', 'projectUpdate')
  .where('featuredProject.projectId = :projectId', { projectId })
  .getOne();

return featuredProject!.projectUpdate;

The backend tests also show that arbitrary HTML is preserved in editProjectUpdate responses rather than normalized/sanitized:

src/resolvers/projectResolver.test.ts

content: '<div>TestProjectUpdateAfterUpdateFateme</div>',
...
assert.equal(
  result.data.data.editProjectUpdate.content,
  '<div>TestProjectUpdateAfterUpdateFateme</div>',
);

I also confirmed with a read-only public GraphQL query to https://mainnet.serve.giveth.io/graphql that featuredProjectUpdate.content is returned as raw HTML for currently featured projects.

Safe reproduction outline

Please run this only in a local/staging environment:

1. Create or seed a project owned by a normal user.
2. Add a normal update as that project owner.
3. Feature that update via AdminJS so a FeaturedUpdate row references it.
4. As the project owner, call:

mutation EditProjectUpdate($updateId: Float!, $title: String!, $content: String!) {
  editProjectUpdate(updateId: $updateId, title: $title, content: $content) {
    id
    title
    content
  }
}

With variables similar to:

{
  "updateId": 123,
  "title": "Update",
  "content": "<p>hello</p><img src=x onerror=\"document.body.setAttribute('data-giveth-xss','1')\">"
}

5. Visit the homepage/featured projects section where ProjectUpdateSlide renders that featured update.
6. Observe that the DOM mutation from the event handler occurs. A real attacker could replace that harmless marker with token theft, UI manipulation, or same-origin API calls.

Suggested fixes

Sanitize project update HTML on the backend with a strict allowlist before storing or returning it. The allowlist should permit only the Quill tags/attributes Giveth intentionally supports, and should block event handler attributes, javascript: URLs, dangerous SVG/MathML, and unsafe inline style.

Also consider replacing the dangerouslySetInnerHTML use in ProjectUpdateSlide with the same safe rendering path used elsewhere, or render a text summary on the homepage card instead of raw rich HTML.

Because already-featured updates can be edited after admin selection, please also consider revalidating/sanitizing existing project_update.content rows and either snapshotting reviewed featured content or requiring re-review after a featured update is edited.

Thank you

[ae2079]

@maryjaf the changes are merged to v5 production

[maryjaf]

2. Giveth admin features that project update via AdminJS.

since the update should be set as feature update and shown in home page , it shouldn't be tested on prod

can I test it on stg? @ae2079

[ae2079]

2. Giveth admin features that project update via AdminJS.

since the update should be set as feature update and shown in home page , it shouldn't be tested on prod

can I test it on stg? @ae2079

Yes, it is also on staging

[maryjaf]

• A project owner creates a benign project update.
• Giveth admin features that project update via AdminJS.
• The project owner later edits the same featured update to include malicious HTML/event attributes.
• The homepage fetches the featured update and injects content directly into the DOM.

I checked with @RamRamez and it seems featured project updates are currently not displayed on the homepage or any other production page.

Before we continue validating the XSS impact, could someone confirm whether featuredProjectUpdate is still consumed anywhere in the production UI?
@ae2079 @RamRamez

[laurenluz]

this issue is on v5 only v6 - @maryjaf

[maryjaf]

This creates a stored XSS path for visitors viewing the homepage/featured project update card. A particularly risky path is:

1. A project owner creates a benign project update.
2. Giveth admin features that project update via AdminJS.
3. The project owner later edits the same featured update to include malicious HTML/event attributes.
4. The homepage fetches the featured update and injects content directly into the DOM.

tested creating a project update with HTML containing an img tag and an onerror handler. The content was rendered as plain text rather than interpreted as HTML, and no JavaScript execution occurred in the update view. Based on this test, I was not able to reproduce XSS through the project update page itself.

The report specifically describes a path where a project update is featured and then rendered through the featured project update component using dangerouslySetInnerHTML. However, featured project updates are not currently displayed in production, so I have not been able to validate the reported execution path or reproduce the issue as described.

https://staging.giveth.io/project/maryam-jafarymehr-0p0p?tab=updates

@ae2079

[ae2079]

Hey @maryjaf, thanks for testing — your findings are correct on both points.

The updates tab renders through RichTextViewer (ReactQuill, read-only), not dangerouslySetInnerHTML, so Quill just shows your <img onerror> as text instead of executing it. Same for project descriptions.

And you're right that the vulnerable featured-update component (ProjectUpdateSlide in homepage/projectUpdatesBlock/) isn't actually mounted on the homepage right now — HomeIndex.tsx uses LatestUpdatesBlock, which only renders contentSummary (plain text). So the live attack path doesn't currently exist on production.

The patch still matters though — the vulnerable code is still in the repo, just unmounted, and the backend was storing raw unsanitized HTML in project_update.content and project.description. So if anyone re-enables that block (or builds something similar) the XSS would come right back. The fix closes it on both sides: backend sanitizes on write + read (PR #2324), frontend swaps dangerouslySetInnerHTML for RichTextViewer (dapps-v2 #5562).

So tl;dr: no live risk today, but a real latent one that's now fixed.