GPU VulnDB

Database/Control plane, storage & DevOps

GitLab CE/EE: malicious wiki content can drive unauthorized actions as another user

CVSS 8.7CVE-2025-12716Control plane, storage & DevOpscurated

Impact

An authenticated GitLab user can craft wiki page content that, when another user views it, performs actions on that user's behalf. On a self-hosted GitLab that drives a GPU fleet, the account being impersonated is often one with runner, registry or deployment rights, so the useful version of this risk is a low-privileged project member escalating through a maintainer who opens a wiki page. GitLab's advisory is deliberately thin - it does not name the sink or the exact set of reachable actions - so treat scope as 'anything the victim's session can do in GitLab' and no more. The scoring (scope-changing, user interaction required) matches a content-injection class issue rather than direct server compromise.

Who can reach it

Any authenticated user who can create or edit a wiki page in a project the target user visits. Requires the victim to view the page (UI:R). Not exploitable by anonymous users unless your instance allows public registration and public project wikis.

What to do

Upgrade the GitLab instance to 18.4.6, 18.5.4 or 18.6.2 depending on your branch, then restart the GitLab services - this is a control-plane application upgrade, not a node-level maintenance window, so GPU nodes keep running and only CI/CD and registry access pause for the restart. Omnibus and chart deployments follow the normal patch-release path; nothing needs to be flashed or drained.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.