TLDR Framework

About

TLDR (Threat, Logs, Detection, Respond) is a public collection of security detections for GitLab. Each detection is one Markdown file that explains the threat, shows the log events it produces, gives a Sigma rule, and says what to do when it fires.

The repository answers the questions you ask when something happens on a GitLab instance, in your words:

• A GitLab security advisory landed: am I exposed (which versions, which offering and tier)?
• Would I see it (which logs carry the signal, and is that log available to me)?
• What do I deploy (a Sigma rule you can convert for your SIEM, and a raw query for when you have none)?
• What do I do when it fires (response steps)?

Who this is for

• Administrators of self-managed and GitLab Dedicated instances, who can collect the application, API, audit and Workhorse logs.
• Owners of GitLab.com groups on Ultimate, who can stream audit events to their own destination.
• Detection engineers who convert Sigma rules to their SIEM's language.
• Incident responders who need the threat, the log evidence and the response steps in one place.

How to navigate

There are two folders under Detections/platforms/GitLab/:

• Threat Detections/: behaviour-based detections (for example a new administrator account, a deploy key created, silent mode enabled).
• Vulnerability Detections/: detections tied to published CVEs, with the affected and fixed versions.

Every file starts with a small YAML frontmatter block that states the offering, tiers, log sources and (for vulnerabilities) the affected versions. index.yaml at the repository root (with an identical index.json) lists all 43 detections in one place, and is generated by scripts/build_index.py. The frontmatter schema is documented in docs/CONTRACT.md.

Starting from an advisory

The table below is generated from index.yaml (python scripts/build_index.py --readme README.md), and --check fails when it is stale. Detection files are listed by file name; the primary detection is the entry point for each CVE. CVE ranges are checked weekly against GitLab's CVE records; see the badge at the top of the project page. Each CVE also carries last_verified.

CVE	fixed in	primary detection	other detections
CVE-2026-105437	19.3.8, 19.4.6, 19.5.4	git_merge_tree_child_process_crash
CVE-2026-110264	18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, 19.5.1	org_mode_render_error_burst	onigmo_native_worker_crash
CVE-2026-85706	18.11.12, 19.0.9, 19.1.8, 19.2.6, 19.3.2	local_file_inclusion_path_enumeration	local_file_inclusion_gitlab_yml_read, local_file_inclusion_metadata_path
CVE-2026-93577	19.2.7, 19.3.3, 19.4.1	ci_lint_workhorse_worker_crash	ci_lint_scripted_client_error_burst, ci_regexp_guard_rejection, graphql_cilint_hostile_regexp, onigmo_native_worker_crash
CVE-2026-97229	19.2.8, 19.3.5, 19.4.2	ci_lint_workhorse_worker_crash	ci_lint_scripted_client_error_burst, ci_regexp_guard_rejection, ci_regexp_oversized_non_ascii_path, graphql_cilint_hostile_regexp, onigmo_native_worker_crash

Self-managed vs GitLab.com

What you can detect depends on what you can collect.

• Self-managed and Dedicated: you can read the application logs on the host or in your cluster (production_json, api_json, application_json, graphql_json, exceptions_json, audit_json, Workhorse, Puma). Both folders apply.
• GitLab.com: you do not have host logs. The only source is audit events streamed to a destination you control, which requires an Ultimate group. Only detections whose frontmatter lists saas in offering apply, and they read audit events only. Streamed events use event_type where audit_json.log uses event_name, so field names differ.

The log source names, paths and availability are in docs/CONTRACT.md. For GitLab's own documentation, see audit event streaming and GitLab logs.

Structure of a detection

Each TLDR detection starts with frontmatter (offering, tier, log sources, scenarios, and for vulnerabilities the CVEs and affected versions) followed by this structure:

1. About: Overview of the threat
2. Threat Details:
   • Technical Details/Impact
   • Business Impact
3. Logs:
   • Required log sources
   • Sample event logs
4. Detection:
   • SIGMA rule or equivalent
   • Raw Log Query (for environments without SIEM)
5. Atomic Test: Instructions to reproduce the threat for testing
6. Response: Guidance on handling the detected threat
7. References: Additional resources and documentation

For a sample TLDR detection, see Maintainer or Owner Permission Added to a Project.