Database/Control plane, storage & DevOps
GitLab CE/EE: unauthenticated crafted requests can deny service to the instance
Impact
An unauthenticated user can send specially crafted requests that GitLab CE/EE does not validate well enough, causing a denial of service. A self-hosted GitLab that runs CI/CD and the image registry for a GPU fleet would stop dispatching jobs and serving pushes while it is degraded. The advisory gives no detail on which endpoint or input is involved.
Who can reach it
Anyone who can reach the GitLab web interface or API over the network. No authentication required.
What to do
Upgrade GitLab CE/EE to 18.9.7, 18.10.6 or 18.11.3 or later (all versions from 9.0 are affected). Upgrading restarts the GitLab services, so expect a short outage of the web UI, API and CI job dispatch.
References
Related entries
- Apache Airflow: session cookie is set at path=/ regardless of base_url, enabling cross-app takeoverCVE-2026-28779 · Apache Airflow (session cookie `_token` path scope)High
- Apache Airflow: SQL error stack traces returned by the API despite expose_stack_traces=falseCVE-2026-30912 · Apache Airflow API (SQL error handling)High
- Apache Airflow: task JWT tokens written to logs let UI users act as Dag authorsCVE-2026-31987 · Apache Airflow (task JWT tokens in logs)High
- Apache Airflow: asset materialize permission lets a user trigger DAGs they have no access toCVE-2026-32228 · Apache Airflow (asset materialize permission)High
- Automated Logic WebCTRL / i-Vu server and controllers, BACnet transport trust: This is the vendor formally concedingCVE-2026-32666 · Automated Logic WebCTRL / i-Vu server and controllers, BACnet transport trustHigh
- Apache Tomcat: Missing encryption of sensitive data introduced by the CVE-2026-29146 fixCVE-2026-34486 · Apache TomcatHigh
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.