GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

4264 vulnerabilities reference this CWE, most recent first.

GHSA-8WXX-35QC-VP6R

Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-10-25 22:07
VLAI
Summary
Missing key verification in gost
Details

An authentication bypass in the SSH service of gost v2.11.5 allows attackers to intercept communications via setting the HostKeyCallback function to ssh.InsecureIgnoreHostKey

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ginuerzh/gost"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.11.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-39223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-25T22:07:23Z",
    "nvd_published_at": "2024-07-03T15:15:06Z",
    "severity": "CRITICAL"
  },
  "details": "An authentication bypass in the SSH service of gost v2.11.5 allows attackers to intercept communications via setting the HostKeyCallback function to ssh.InsecureIgnoreHostKey",
  "id": "GHSA-8wxx-35qc-vp6r",
  "modified": "2024-10-25T22:07:23Z",
  "published": "2024-07-03T18:48:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39223"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ginuerzh/gost/issues/1034"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/nyxfqq/a7242170b1118e78436a62dee4e09e8a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ginuerzh/gost"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ginuerzh/gost/blob/729d0e70005607dc7c69fc1de62fd8fe21f85355/ssh.go#L229"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing key verification in gost"
}

GHSA-8X5Q-GQ29-2H75

Vulnerability from github – Published: 2024-08-13 18:31 – Updated: 2024-08-15 21:31
VLAI
Details

Improper key usage control in AMD Secure Processor (ASP) may allow an attacker with local access who has gained arbitrary code execution privilege in ASP to extract ASP cryptographic keys, potentially resulting in loss of confidentiality and integrity.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21981"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T17:15:22Z",
    "severity": "MODERATE"
  },
  "details": "Improper key usage control in AMD Secure Processor\n(ASP) may allow an attacker with local access who has gained arbitrary code\nexecution privilege in ASP\u00a0to\nextract ASP cryptographic keys, potentially resulting in loss of\nconfidentiality and integrity.",
  "id": "GHSA-8x5q-gq29-2h75",
  "modified": "2024-08-15T21:31:19Z",
  "published": "2024-08-13T18:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21981"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3003.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8X7X-83CF-C3PG

Vulnerability from github – Published: 2026-08-28 16:08 – Updated: 2026-08-28 16:08
VLAI
Summary
Hatchet allows cross-tenant write/DoS to other tenants' workers via Dispatcher gRPC UpsertWorkerLabels and Unsubscribe
Details

Summary

A cross-tenant write / DoS vulnerability in the Hatchet Dispatcher gRPC service allows any holder of a normal tenant-scoped API token (the lowest credential Hatchet issues — an OWNER of a brand-new tenant) to overwrite the affinity labels of, or disconnect from the dispatcher, any worker UUID belonging to any other tenant on the same Hatchet instance. The two affected RPCs — Dispatcher/UpsertWorkerLabels and Dispatcher/Unsubscribe — read the caller's tenant from the bearer-token context only for analytics and response shaping, and never use it to authorise the worker_id from the request body.

Impact

This CVE requires the attacker to successfully guess the target UUID. Who is impacted. Any Hatchet deployment that hosts more than one tenant on the same instance: - Hatchet Cloud (multi-tenant SaaS) — every tenant is exposed to every other tenant. - Self-hosted Hatchet with multiple internal teams / business units sharing one instance — each team is exposed to every other team on the box. - Any deployment where a single tenant's API token can be obtained by an attacker (e.g. a leaked low-privilege CI token from a single tenant). One token is enough to attack every other tenant on the same instance.

Single-tenant self-hosted deployments are unaffected in practice (the "victim" and "attacker" tenants would be the same).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hatchet-dev/hatchet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.40.0"
            },
            {
              "fixed": "0.91.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54746"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:08:58Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA **cross-tenant write / DoS** vulnerability in the Hatchet `Dispatcher` gRPC service allows any holder of a normal tenant-scoped API token (the lowest credential Hatchet issues \u2014 an `OWNER` of a brand-new tenant) to overwrite the affinity labels of, or disconnect from the dispatcher, any worker UUID belonging to any other tenant on the same Hatchet instance. The two affected RPCs \u2014 `Dispatcher/UpsertWorkerLabels` and `Dispatcher/Unsubscribe` \u2014 read the caller\u0027s tenant from the bearer-token context only for analytics and response shaping, and never use it to authorise the `worker_id` from the request body.\n\n\n### Impact\nThis CVE requires the attacker to successfully guess the target UUID. \n**Who is impacted.** Any Hatchet deployment that hosts more than one tenant on the same instance:\n- **Hatchet Cloud (multi-tenant SaaS)** \u2014 every tenant is exposed to every other tenant.\n- **Self-hosted Hatchet with multiple internal teams / business units sharing one instance** \u2014 each team is exposed to every other team on the box.\n- **Any deployment where a single tenant\u0027s API token can be obtained by an attacker** (e.g. a leaked low-privilege CI token from a single tenant). One token is enough to attack every other tenant on the same instance.\n\nSingle-tenant self-hosted deployments are unaffected in practice (the \"victim\" and \"attacker\" tenants would be the same).",
  "id": "GHSA-8x7x-83cf-c3pg",
  "modified": "2026-08-28T16:08:58Z",
  "published": "2026-08-28T16:08:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hatchet-dev/hatchet/security/advisories/GHSA-8x7x-83cf-c3pg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hatchet-dev/hatchet/commit/591a30deb8b80f02eba7014997de387d710986c9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hatchet-dev/hatchet"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Hatchet allows cross-tenant write/DoS to other tenants\u0027 workers via Dispatcher gRPC UpsertWorkerLabels and Unsubscribe"
}

GHSA-8XFC-9Q6X-H2XP

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-07-13 00:00
VLAI
Details

vFairs 3.3 is affected by Insecure Permissions. Any user logged in to a vFairs virtual conference or event can modify any other users profile information or profile picture. After receiving any user's unique identification number and their own, an HTTP POST request can be made update their profile description or supply a new profile image. This can lead to potential cross-site scripting attacks on any user, or upload malicious PHP webshells as "profile pictures." The user IDs can be easily determined by other responses from the API for an event or chat room.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-26679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-276",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-26T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "vFairs 3.3 is affected by Insecure Permissions. Any user logged in to a vFairs virtual conference or event can modify any other users profile information or profile picture. After receiving any user\u0027s unique identification number and their own, an HTTP POST request can be made update their profile description or supply a new profile image. This can lead to potential cross-site scripting attacks on any user, or upload malicious PHP webshells as \"profile pictures.\" The user IDs can be easily determined by other responses from the API for an event or chat room.",
  "id": "GHSA-8xfc-9q6x-h2xp",
  "modified": "2022-07-13T00:00:50Z",
  "published": "2022-05-24T19:03:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26679"
    },
    {
      "type": "WEB",
      "url": "https://api.vfairs.com/v1/profiles"
    },
    {
      "type": "WEB",
      "url": "https://api.vfairs.com/v1/profiles?access_key="
    },
    {
      "type": "WEB",
      "url": "https://www.huntress.com/blog/zero-day-vulnerabilities-in-popular-event-management-platforms-could-leave-msps-open-to-attack"
    },
    {
      "type": "WEB",
      "url": "http://vfairs.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8XJM-WQRP-2F25

Vulnerability from github – Published: 2026-08-20 18:38 – Updated: 2026-08-20 18:38
VLAI
Summary
Laravel Backpack CRUD: Arbitrary file deletion via attacker-controlled clear_<attr>[] in HasUploadFields::uploadMultipleFilesToDisk
Details

Summary

HasUploadFields::uploadMultipleFilesToDisk (in src/app/Models/Traits/HasUploadFields.php) reads file paths from the clear_<attribute>[] request input and deletes them from the configured storage disk without verifying that the paths belong to the current model record.

An authenticated user with Update access on any CRUD that wires uploadMultipleFilesToDisk as a model mutator (the pattern documented in the v5.x upload_multiple field guide) can supply arbitrary disk-relative paths in clear_<attr>[] to delete files that were never associated with the record they are editing.

The safe pattern already exists in the codebase: src/app/Library/Uploaders/MultipleFiles.php intersects the requested deletions against the files currently stored in the database column before calling Storage::disk()->delete(). The trait method lacks that intersection.

Affected code

  • src/app/Models/Traits/HasUploadFields.phpuploadMultipleFilesToDisk (primary sink)
  • src/app/Models/Traits/CrudTrait.php — mixes HasUploadFields into all Backpack-managed models

The vulnerability is present in all 5.x, 6.x < 6.8.12, and 7.x < 7.0.35 releases.

Impact

An attacker with low-privilege Backpack admin access (e.g. a content editor) can delete any file under the configured disk root: other records' attachments, shared assets, or files placed on the same disk for operational purposes. No confidentiality impact (files cannot be read, only deleted).

CWE-285 (Authorization Bypass) / CWE-639 (IDOR on file deletion)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High

Fix

Intersect $files_to_clear against the filenames currently persisted on the model before calling delete(), mirroring the logic already present in MultipleFiles::uploadFiles. Fixed in 6.8.12 and 7.0.35.

Deployments still using the uploadMultipleFilesToDisk mutator pattern from the v5.x docs should migrate to the Uploader API (MultipleFiles::class via config/backpack/crud.php), which applies the safe intersection automatically.

Credits

Reported by Vishal Shukla (@shukla304).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 6.0.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "backpack/crud"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "backpack/crud"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.8.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "backpack/crud"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.35"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T18:38:39Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`HasUploadFields::uploadMultipleFilesToDisk` (in `src/app/Models/Traits/HasUploadFields.php`) reads file paths from the `clear_\u003cattribute\u003e[]` request input and deletes them from the configured storage disk **without verifying that the paths belong to the current model record**.\n\nAn authenticated user with Update access on any CRUD that wires `uploadMultipleFilesToDisk` as a model mutator (the pattern documented in the v5.x `upload_multiple` field guide) can supply arbitrary disk-relative paths in `clear_\u003cattr\u003e[]` to delete files that were never associated with the record they are editing.\n\nThe safe pattern already exists in the codebase: `src/app/Library/Uploaders/MultipleFiles.php` intersects the requested deletions against the files currently stored in the database column before calling `Storage::disk()-\u003edelete()`. The trait method lacks that intersection.\n\n## Affected code\n\n- `src/app/Models/Traits/HasUploadFields.php` \u2014 `uploadMultipleFilesToDisk` (primary sink)\n- `src/app/Models/Traits/CrudTrait.php` \u2014 mixes `HasUploadFields` into all Backpack-managed models\n\nThe vulnerability is present in all 5.x, 6.x \u003c 6.8.12, and 7.x \u003c 7.0.35 releases.\n\n## Impact\n\nAn attacker with low-privilege Backpack admin access (e.g. a content editor) can delete any file under the configured disk root: other records\u0027 attachments, shared assets, or files placed on the same disk for operational purposes. No confidentiality impact (files cannot be read, only deleted).\n\n**CWE-285** (Authorization Bypass) / **CWE-639** (IDOR on file deletion)  \nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = **8.1 High**\n\n## Fix\n\nIntersect `$files_to_clear` against the filenames currently persisted on the model before calling `delete()`, mirroring the logic already present in `MultipleFiles::uploadFiles`. Fixed in **6.8.12** and **7.0.35**.\n\nDeployments still using the `uploadMultipleFilesToDisk` mutator pattern from the v5.x docs should migrate to the Uploader API (`MultipleFiles::class` via `config/backpack/crud.php`), which applies the safe intersection automatically.\n\n## Credits\n\nReported by Vishal Shukla ([@shukla304](https://github.com/shukla304)).",
  "id": "GHSA-8xjm-wqrp-2f25",
  "modified": "2026-08-20T18:38:39Z",
  "published": "2026-08-20T18:38:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Laravel-Backpack/CRUD/security/advisories/GHSA-8xjm-wqrp-2f25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Laravel-Backpack/CRUD"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Laravel-Backpack/CRUD/releases/tag/6.8.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Laravel-Backpack/CRUD/releases/tag/7.0.35"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Laravel Backpack CRUD: Arbitrary file deletion via attacker-controlled clear_\u003cattr\u003e[] in HasUploadFields::uploadMultipleFilesToDisk"
}

GHSA-8XJV-X6F3-C657

Vulnerability from github – Published: 2025-03-03 15:31 – Updated: 2026-06-02 09:36
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in Proliz Software OBS allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects OBS: before 24.0927.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-8261"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-03T15:15:15Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Proliz Software OBS allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects OBS: before 24.0927.",
  "id": "GHSA-8xjv-x6f3-c657",
  "modified": "2026-06-02T09:36:14Z",
  "published": "2025-03-03T15:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8261"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0049"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-25-0049"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9284-FJC3-FMMJ

Vulnerability from github – Published: 2026-08-24 19:40 – Updated: 2026-08-24 19:40
VLAI
Summary
Sakai Profile Image Deletion has an IDOR
Details

Summary

The Sakai REST API endpoint DELETE /api/users/{userId}/profile/image does not verify that the requesting user is authorized to modify the target user's profile. Any authenticated user can delete the profile image of any other user, including administrators, by supplying a different userId in the path. The service layer has no authorization check, and the delete cascades through Content Hosting Service (CHS) with a security advisor that bypasses all CHS permission checks.

Details

ProfileController.removeProfileImage() in the webapi module retrieves the current user's session but performs no comparison between the authenticated user and the target userId path parameter:

@DeleteMapping(value = "/users/{userId}/profile/image")
public ResponseEntity<String> removeProfileImage(@PathVariable String userId) {
    String currentUserId = checkSakaiSession().getUserId();
    if (currentUserId == null) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    profileService.removeProfileImage(userId);  // userId is attacker-controlled
    return ResponseEntity.ok().build();
}

ProfileServiceImpl.removeProfileImage() delegates directly to dao.removeProfileImage(userUuid) with no authorization check. The DAO calls profileImageUploadedRepository.deleteById(userId), removing the profile_images_t row unconditionally.

For contrast, the upload endpoint setProfileImage() correctly verifies ownership:

if (!sakaiProxy.isSuperUser() && !StringUtils.equals(currentUserUuid, userUuid)) {
    throw new SecurityException("Not allowed to save.");
}

This asymmetry means any authenticated user can delete but not upload over another user's profile image.

Additionally, the pronunciation recording delete endpoint (DELETE /api/users/{userId}/profile/pronunciation) has no checkSakaiSession() call at all, making it accessible without any authentication.

Setup: - Admin user: admin, with a custom profile image uploaded - Attacker: student2 (unprivileged user, SAKAIID cookie from authenticated session)

Step 1 - Admin uploads profile image (confirm non-default state):

POST /api/users/admin/profile/image HTTP/1.1
Cookie: SAKAIID=<admin-session>
Content-Type: application/x-www-form-urlencoded

base64=<base64-encoded-png>

Response: {"status":"SUCCESS"}

Step 2 - Verify image exists in database:

SELECT USER_UUID, RESOURCE_MAIN FROM profile_images_t WHERE USER_UUID='admin';
-- Result: admin | /private/profileImages/admin/1/eb92b129-9b00-4978-aec3-be840455d8e9

Step 3 - Attacker (student2) deletes admin's profile image:

DELETE /api/users/admin/profile/image HTTP/1.1
Host: localhost:9107
Cookie: SAKAIID=974996f4-e9c1-441c-9ab9-d3646aa5c754.9799861f31fb

Response: HTTP/1.1 200

Step 4 - Verify image is gone from database:

SELECT USER_UUID, RESOURCE_MAIN FROM profile_images_t WHERE USER_UUID='admin';
-- Result: (empty - row deleted)

The attack succeeds. Student2's session is accepted by checkSakaiSession() (non-blank userId), and the target userId (admin) is passed directly to the service without any ownership check.

Impact

Any authenticated user (student, guest) can: - Permanently delete the profile image of any other user, including administrators and instructors - Repeatedly trigger deletion to prevent a target user from maintaining a profile picture - In a university context where profile photos are used for identity verification in proctored exams or student directories, this could disrupt identity management workflows

The attack is trivially scriptable and can target all users on the platform in bulk.

Suggested Remediation

In ProfileController.removeProfileImage(), add an ownership check before calling the service:

@DeleteMapping(value = "/users/{userId}/profile/image")
public ResponseEntity<String> removeProfileImage(@PathVariable String userId) {
    Session session = checkSakaiSession();
    String currentUserId = session.getUserId();
    if (currentUserId == null) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    // Add this check:
    if (!sakaiProxy.isSuperUser() && !currentUserId.equals(userId)) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    profileService.removeProfileImage(userId);
    return ResponseEntity.ok().build();
}

Apply the same ownership check in ProfileServiceImpl.removeProfileImage() for defense-in-depth, mirroring the pattern in setProfileImage().

For the pronunciation endpoint, add checkSakaiSession() and the same ownership check.

Status / timeline:

  • 2026-06-02: Fix committed to master (a092dbf3dc6bf343131f50007c207a9abd95e852)
  • Release pending.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.sakaiproject.profile2:profile2-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0"
            },
            {
              "fixed": "23.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.sakaiproject.profile2:profile2-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0"
            },
            {
              "last_affected": "25.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.sakaiproject.profile2:profile2-impl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0"
            },
            {
              "fixed": "23.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.sakaiproject.profile2:profile2-impl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0"
            },
            {
              "last_affected": "25.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54050"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-24T19:40:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe Sakai REST API endpoint `DELETE /api/users/{userId}/profile/image` does not verify that the requesting user is authorized to modify the target user\u0027s profile. Any authenticated user can delete the profile image of any other user, including administrators, by supplying a different `userId` in the path. The service layer has no authorization check, and the delete cascades through Content Hosting Service (CHS) with a security advisor that bypasses all CHS permission checks.\n\n### Details\n`ProfileController.removeProfileImage()` in the webapi module retrieves the current user\u0027s session but performs no comparison between the authenticated user and the target `userId` path parameter:\n\n```java\n@DeleteMapping(value = \"/users/{userId}/profile/image\")\npublic ResponseEntity\u003cString\u003e removeProfileImage(@PathVariable String userId) {\n    String currentUserId = checkSakaiSession().getUserId();\n    if (currentUserId == null) {\n        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();\n    }\n    profileService.removeProfileImage(userId);  // userId is attacker-controlled\n    return ResponseEntity.ok().build();\n}\n```\n\n`ProfileServiceImpl.removeProfileImage()` delegates directly to `dao.removeProfileImage(userUuid)` with no authorization check. The DAO calls `profileImageUploadedRepository.deleteById(userId)`, removing the `profile_images_t` row unconditionally.\n\nFor contrast, the upload endpoint `setProfileImage()` correctly verifies ownership:\n\n```java\nif (!sakaiProxy.isSuperUser() \u0026\u0026 !StringUtils.equals(currentUserUuid, userUuid)) {\n    throw new SecurityException(\"Not allowed to save.\");\n}\n```\n\nThis asymmetry means any authenticated user can delete but not upload over another user\u0027s profile image.\n\nAdditionally, the pronunciation recording delete endpoint (`DELETE /api/users/{userId}/profile/pronunciation`) has no `checkSakaiSession()` call at all, making it accessible without any authentication.\n\n\n**Setup:**\n- Admin user: `admin`, with a custom profile image uploaded\n- Attacker: `student2` (unprivileged user, SAKAIID cookie from authenticated session)\n\n**Step 1 - Admin uploads profile image (confirm non-default state):**\n\n```\nPOST /api/users/admin/profile/image HTTP/1.1\nCookie: SAKAIID=\u003cadmin-session\u003e\nContent-Type: application/x-www-form-urlencoded\n\nbase64=\u003cbase64-encoded-png\u003e\n```\n\nResponse: `{\"status\":\"SUCCESS\"}`\n\n**Step 2 - Verify image exists in database:**\n\n```sql\nSELECT USER_UUID, RESOURCE_MAIN FROM profile_images_t WHERE USER_UUID=\u0027admin\u0027;\n-- Result: admin | /private/profileImages/admin/1/eb92b129-9b00-4978-aec3-be840455d8e9\n```\n\n**Step 3 - Attacker (student2) deletes admin\u0027s profile image:**\n\n```\nDELETE /api/users/admin/profile/image HTTP/1.1\nHost: localhost:9107\nCookie: SAKAIID=974996f4-e9c1-441c-9ab9-d3646aa5c754.9799861f31fb\n```\n\nResponse: `HTTP/1.1 200`\n\n**Step 4 - Verify image is gone from database:**\n\n```sql\nSELECT USER_UUID, RESOURCE_MAIN FROM profile_images_t WHERE USER_UUID=\u0027admin\u0027;\n-- Result: (empty - row deleted)\n```\n\nThe attack succeeds. Student2\u0027s session is accepted by `checkSakaiSession()` (non-blank userId), and the target userId (`admin`) is passed directly to the service without any ownership check.\n\n### Impact\n\nAny authenticated user (student, guest) can:\n- Permanently delete the profile image of any other user, including administrators and instructors\n- Repeatedly trigger deletion to prevent a target user from maintaining a profile picture\n- In a university context where profile photos are used for identity verification in proctored exams or student directories, this could disrupt identity management workflows\n\nThe attack is trivially scriptable and can target all users on the platform in bulk.\n\n### Suggested Remediation\n\nIn `ProfileController.removeProfileImage()`, add an ownership check before calling the service:\n\n```java\n@DeleteMapping(value = \"/users/{userId}/profile/image\")\npublic ResponseEntity\u003cString\u003e removeProfileImage(@PathVariable String userId) {\n    Session session = checkSakaiSession();\n    String currentUserId = session.getUserId();\n    if (currentUserId == null) {\n        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();\n    }\n    // Add this check:\n    if (!sakaiProxy.isSuperUser() \u0026\u0026 !currentUserId.equals(userId)) {\n        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();\n    }\n    profileService.removeProfileImage(userId);\n    return ResponseEntity.ok().build();\n}\n```\n\nApply the same ownership check in `ProfileServiceImpl.removeProfileImage()` for defense-in-depth, mirroring the pattern in `setProfileImage()`.\n\nFor the pronunciation endpoint, add `checkSakaiSession()` and the same ownership check.\n\n### Status / timeline:\n- 2026-06-02: Fix committed to master (`a092dbf3dc6bf343131f50007c207a9abd95e852`)\n- Release pending.",
  "id": "GHSA-9284-fjc3-fmmj",
  "modified": "2026-08-24T19:40:37Z",
  "published": "2026-08-24T19:40:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sakaiproject/sakai/security/advisories/GHSA-9284-fjc3-fmmj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sakaiproject/sakai/commit/a092dbf3dc6bf343131f50007c207a9abd95e852"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sakaiproject/sakai"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sakaiproject/sakai/releases/tag/23.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sakai Profile Image Deletion has an IDOR"
}

GHSA-9285-889V-MP3C

Vulnerability from github – Published: 2026-08-11 15:32 – Updated: 2026-09-01 21:31
VLAI
Details

n8n before 1.123.67, 2.31.5, and 2.32.1 validates credential-access only for a node's top-level credentials and not for credentials referenced inside an Execute Sub-workflow node's inline workflow JSON. A member with Editor access to a shared workflow (when workflow sharing is enabled) who knows a target credential's ID can reference that credential in the inline JSON; it passes save-time and runtime validation and resolves in the parent workflow's project context, allowing the attacker to use or exfiltrate credentials they are not permitted to access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-72763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T13:19:06Z",
    "severity": "HIGH"
  },
  "details": "n8n before 1.123.67, 2.31.5, and 2.32.1 validates credential-access only for a node\u0027s top-level credentials and not for credentials referenced inside an Execute Sub-workflow node\u0027s inline workflow JSON. A member with Editor access to a shared workflow (when workflow sharing is enabled) who knows a target credential\u0027s ID can reference that credential in the inline JSON; it passes save-time and runtime validation and resolves in the parent workflow\u0027s project context, allowing the attacker to use or exfiltrate credentials they are not permitted to access.",
  "id": "GHSA-9285-889v-mp3c",
  "modified": "2026-09-01T21:31:16Z",
  "published": "2026-08-11T15:32:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-cj9h-qx8g-pq2g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72763"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/n8n-before-credential-exfiltration-via-sub-workflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-92CG-GHQ6-9587

Vulnerability from github – Published: 2023-12-12 03:31 – Updated: 2024-09-30 18:52
Withdrawn 2024-09-30 VLAI
Summary
Duplicate Advisory: Privilege escalation in sap/cloud-security-client-go
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-m8rw-rcpq-2vp2. This link is maintained to preserve external references.

Original Description

SAP BTP Security Services Integration Library ([Golang] github.com/sap/cloud-security-client-go) - versions < 0.17.0, allow under certain conditions an escalation of privileges. On successful exploitation, an unauthenticated attacker can obtain arbitrary permissions within the application.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sap/cloud-security-client-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-639",
      "CWE-749"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-15T03:39:45Z",
    "nvd_published_at": "2023-12-12T03:15:07Z",
    "severity": "CRITICAL"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-m8rw-rcpq-2vp2. This link is maintained to preserve external references.\n\n## Original Description\nSAP\u00a0BTP\u00a0Security Services Integration Library ([Golang] github.com/sap/cloud-security-client-go) - versions \u003c 0.17.0, allow under certain conditions an escalation of privileges. On successful exploitation, an unauthenticated attacker can obtain arbitrary permissions within the application.\n\n",
  "id": "GHSA-92cg-ghq6-9587",
  "modified": "2024-09-30T18:52:24Z",
  "published": "2023-12-12T03:31:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SAP/cloud-security-services-integration-library/security/advisories/GHSA-59c9-pxq8-9c73"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50424"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAP/cloud-security-client-go/commit/2e3bd63e152e09f267316a1071034eb5d4b7f498"
    },
    {
      "type": "WEB",
      "url": "https://blogs.sap.com/2023/12/12/unveiling-critical-security-updates-sap-btp-security-note-3411067"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SAP/cloud-security-client-go"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3411067"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/github.com/sap/cloud-security-client-go@v0.17.0"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Privilege escalation in sap/cloud-security-client-go",
  "withdrawn": "2024-09-30T18:52:24Z"
}

GHSA-92QM-MQ2F-95W2

Vulnerability from github – Published: 2024-05-02 18:30 – Updated: 2026-04-08 18:33
VLAI
Details

The FileBird – WordPress Media Library Folders & File Manager plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 5.6.3 via folder deletion due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with author access or higher, to delete folders created by other users and make their file uploads visible.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-2346"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-02T17:15:16Z",
    "severity": "MODERATE"
  },
  "details": "The FileBird \u2013 WordPress Media Library Folders \u0026 File Manager plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 5.6.3 via folder deletion due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with author access or higher, to delete folders created by other users and make their file uploads visible.",
  "id": "GHSA-92qm-mq2f-95w2",
  "modified": "2026-04-08T18:33:03Z",
  "published": "2024-05-02T18:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2346"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3060898%40filebird%2Ftrunk\u0026old=3049188%40filebird%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/82cde234-ae87-438f-911e-bdd0e3ac1132?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.