CVE-2025-4278

Think of GitLab’s new search page like a shared “display board.” This bug lets a user slip in harmful instructions into that board. If another person opens or uses the tainted search page, the attacker can take over that other person’s account—like tricking someone into signing into a fake version of your system.

This matters if you run GitLab and you’re using GitLab 18.0 before 18.0.2. The risk is highest when an attacker has a low-level (logged-in) GitLab account and your users interact with the tainted new search page.
Only consider it a practical risk when both conditions are true: there is an attacker with an account inside your GitLab, and the targeted user interacts with the compromised search view.

Treat this as urgent because attackers can use a low-privilege account to inject scripts through GitLab’s new search and then take over other users when they interact with the page.
A public exploit exists, and the overall likelihood indicators are rising, so you should upgrade to the fixed version without delay.

1. Confirm exposure (what to check)

   • Identify the exact GitLab version in use (GitLab Admin area / system information or your deployment manifest).
   • Determine whether it is any release “starting with 18.0 before 18.0.2.” If yes, you are in the affected range.

2. Apply the fix (target versions)

   • Upgrade GitLab to 18.0.2 or above.
   • If you manage multiple environments (prod/staging), patch production first only when you can do it safely, but ensure staging gets the same upgrade soon after to keep behavior consistent.

3. Validate after upgrade

   • Open the new search page as a normal user and ensure results render as expected.
   • Look for authentication/session anomalies: sudden account/session changes, logins from unusual browser/device patterns, or unexpected “account takeover” symptoms around the time of access to the search page.

4. If you cannot patch immediately (containment)

   • Reduce the chance of a malicious low-privilege account being able to exploit the search feature:
     • Review and lock down user access so only trusted users can log into GitLab.
     • Disable or remove any suspicious/unused low-privilege accounts.
   • Increase monitoring of login and session behavior for users who access the new search feature.

5. Ongoing monitoring

   • After patching, continue monitoring for suspicious session activity for at least a short window (for example, the typical business cycle where users frequently use search).
   • If you have alerts for unusual logins or session changes, ensure they are enabled and routed to the right on-call person.

CISA KEV note

• This CVE is not listed in the CISA KEV catalog based on the provided findings.

Severity is HIGH (CVSS 8.7). This is a weakness of type CWE-80 (basic XSS). The described mechanism is improper neutralization of script-related HTML tags in a web page, specifically within GitLab’s new search interface.

Attack mechanism and prerequisites (from the findings)

• Authenticated attacker with low privileges can inject malicious code into the new search page.
• The attack requires user interaction: another user must interact with the compromised search view.
• Preconditions: attacker has a low-level user account; the target must be interacting with the new search page.

Exploitation status

• Public exploit available (1 known).
• KEV is not listed (so no CISA KEV confirmation from the provided findings), but the findings indicate press attention rising.

EPSS

• A predicted likelihood score is provided as rising; do not use it as proof of active exploitation. (No KEV confirmation is included in the findings.)

Fix

• GitLab is fixed in 18.0.2; upgrade to 18.0.2 or above per the provided patch information.