Hardening GitLab CI/CD: Blue Team CVE-2024-6385 Pipeline Defense

Md. Redwan Ahmed Md. Redwan Ahmed
·
Hardening GitLab CI/CD: Blue Team CVE-2024-6385 Pipeline Defense

Overview & Defensive Context: The Demise of Implicit Pipeline Trust#

Harden GitLab CI/CD against CVE-2024-6385: upgrade to 17.1.2+, isolate runner networks, migrate to external secrets, and audit pipeline triggers.

In our morning threat architecture analysis, we deconstructed the offensive mechanics of GitLab CVE-2024-6385 (classified under CWE-284: Improper Access Control, CVSS 9.6 Critical) and related vulnerability CVE-2024-5655, mapped to MITRE ATT&CK T1190: Exploit Public-Facing Application, T1548: Abuse Elevation Control Mechanism, and T1552.004: Unsecured Credentials: Private Keys / Environment Secrets. We demonstrated how an unprivileged developer or external fork contributor can exploit authorization logic defects in GitLab's Ruby on Rails backend service (Ci::CreatePipelineService). By triggering merge request pipelines or multi-project pipeline chains under specific conditions, the framework assigns the execution identity of the pipeline to a project Maintainer or Owner rather than the initiating actor. This allows the adversary to bypass branch protection rules, execute arbitrary scripts inside privileged runner environments, and harvest all masked and protected CI/CD variables (including production AWS IAM keys, Kubernetes kubeconfigs, and deploy tokens).

For DevSecOps leads, CI/CD platform architects, and enterprise blue teams, defending automated build pipelines against pipeline takeover exposes systemic flaws in conventional DevSecOps assumptions:

  • The Fallacy of Static Environment Variables: For years, software engineering teams have treated GitLab's "Protected and Masked" variable settings as an infallible vault for sensitive production infrastructure secrets. However, environment variables injected into a CI/CD job container are accessible to any arbitrary shell script executing within .gitlab-ci.yml. If an authorization defect allows an unprivileged actor to execute a pipeline in a protected context, every static secret configured in project or group settings is instantly compromised. Securing the modern software supply chain mandates moving away from static secrets toward dynamic, short-lived OIDC identity federation.
  • The Danger of Privileged Docker-in-Docker Runners: To allow developers to build container images inside CI/CD jobs, platform teams routinely configure GitLab Runners with the Docker executor in privileged mode (privileged = true with docker:dind). If an attacker hijacks a pipeline via CVE-2024-6385, the executing script gains unrestricted access to the runner host's kernel, enabling immediate container breakouts, host persistence, and lateral movement into the runner's internal subnet.
  • The Necessity of Independent Pipeline Authorization Checks: Monolithic platforms like GitLab bundle repository hosting, identity management, code review, and pipeline execution into a shared database and service layer. When identity resolution logic fails during pipeline instantiation, all downstream authorization checks—including runner tags and environment protection rules—inherit the corrupted user identity. True defense-in-depth requires establishing decoupled verification gates, mandatory merge request approvals, and external secrets management.
  • The Blueprint for Enterprise GitLab CI/CD Hardening: Completely securing GitLab pipelines against unauthorized execution and secret harvesting requires deploying controls across five distinct tiers: upgrading GitLab instances to patched release baselines (17.1.2+, 17.0.3+, or 16.11.5+), migrating static CI/CD variables to dynamic HashiCorp Vault / AWS OIDC JWT tokens, hardening GitLab Runners (deprecating privileged DinD and enforcing network egress filtering), enforcing branch and merge request approval policies, and instrumenting SIEM detection rules on audit_json.log.
Warning

While updating GitLab patches the vulnerability, any static CI/CD variables exposed on vulnerable instances prior to patching must be considered compromised and immediately rotated across cloud providers.

⚔️ Exploitation Mechanics: For root-cause memory corruption analysis and attack flow, see our deep-dive: Deconstructing Breakdown.

Architecture Hardening: Five-Tier Defense-in-Depth for GitLab CI/CD#

Securing enterprise GitLab deployments against pipeline hijacking, unauthorized user delegation, and secret leakage requires implementing architectural controls across platform versions, secrets architecture, runner infrastructure, pipeline policies, and SIEM telemetry.

Defense Architecture Flowchart#

flowchart TD
    classDef client fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef gate fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef secure fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef audit fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef pass fill:#065f46,stroke:#34d399,stroke-width:2px,color:#a7f3d0

    Attacker[Unprivileged Actor Submits Fork MR or API Trigger Request]:::client --> VersionGate{Tier 1: GitLab Rails Version Verification Gate}:::gate

    VersionGate -- Vulnerable GitLab Version <= 17.1.1 Unpatched --> VulnDelegation[Ci::CreatePipelineService Swaps Identity to Maintainer]:::drop
    VersionGate -- Patched GitLab Version >= 17.1.2 Installed --> StrictAuth[Enforce Strict Invoking User Identity Validation]:::pass

    StrictAuth --> PolicyGate{Tier 2: Pipeline Approval & Branch Policy Gate}:::gate
    PolicyGate -- Unapproved Fork MR Attempting Protected Execution --> BlockMR[Action: Drop Pipeline / Require Maintainer Approval]:::drop
    PolicyGate -- Verified Protected Branch Commit by Authorized Maintainer --> SecretsGate{Tier 3: Secrets Architecture Gate}:::gate

    SecretsGate -- Static Protected Variables Injected into Job --> StaticRisk[Warning: Static AWS / K8s Keys Exposed in Environment]:::drop
    SecretsGate -- Dynamic OIDC JWT Federation via HashiCorp Vault --> VendedTokens[Action: Short-Lived Ephemeral Token Vended per Job]:::secure

    VendedTokens --> RunnerGate{Tier 4: GitLab Runner Isolation & Egress Gate}:::gate
    RunnerGate -- Privileged Docker-in-Docker or Host Network Access --> RunnerEscape[Vulnerability: Runner Host Compromise via DinD Escape]:::drop
    RunnerGate -- Ephemeral VM Runner + Unprivileged OCI + Network Denied --> SecureBuild[Safe Execution: Zero Egress & Zero Host Mounts]:::secure

    SecureBuild --> AuditGate{Tier 5: Audit Telemetry & SIEM Monitoring}:::gate
    AuditGate --> LogAudit[Audit_json.log & Falco Verify Zero Identity Anomalies]:::audit

Tier 1: Platform Remediation & Distribution Version Auditing#

The primary fix for CVE-2024-6385 is upgrading GitLab Community and Enterprise Editions to releases containing the patched Ci::CreatePipelineService logic:

  • GitLab 17.1.2 or higher (for 17.1.x series)
  • GitLab 17.0.3 or higher (for 17.0.x series)
  • GitLab 16.11.5 or higher (for 16.11.x series)

Automated Bash Script: Auditing GitLab Instance Version

Deploy and execute this verification script on your GitLab server host or via administrative CI/CD jobs:

BASH 
#!/usr/bin/env bash
# audit_gitlab_patch.sh - Audit GitLab version against CVE-2024-6385 and CVE-2024-5655
set -euo pipefail

echo "[*] Auditing local GitLab instance for CVE-2024-6385 remediation..."

# Extract version from Omnibus or GitLab environment
if command -v gitlab-rake >/dev/null 2>&1; then
    GITLAB_VER=$(gitlab-rake gitlab:env:info 2>/dev/null | grep "Version:" | awk '{print $2}')
elif [ -f /opt/gitlab/version-manifest.txt ]; then
    GITLAB_VER=$(head -n 1 /opt/gitlab/version-manifest.txt | awk '{print $2}')
else
    echo "[!] Cannot determine GitLab version directly. Querying API..."
    GITLAB_VER=$(curl -s "https://gitlab.corp.internal/api/v4/version" --header "PRIVATE-TOKEN: $ADMIN_TOKEN" | jq -r .version)
fi

echo "[*] Detected GitLab Version: ${GITLAB_VER}"

# Evaluate version against patch baselines
VULN=0
MAJOR=$(echo "$GITLAB_VER" | cut -d'.' -f1)
MINOR=$(echo "$GITLAB_VER" | cut -d'.' -f2)
PATCH=$(echo "$GITLAB_VER" | cut -d'.' -f3 | cut -d'-' -f1)

if [ "$MAJOR" -eq 17 ]; then
    if [ "$MINOR" -eq 1 ] && [ "$PATCH" -lt 2 ]; then VULN=1; fi
    if [ "$MINOR" -eq 0 ] && [ "$PATCH" -lt 3 ]; then VULN=1; fi
elif [ "$MAJOR" -eq 16 ]; then
    if [ "$MINOR" -eq 11 ] && [ "$PATCH" -lt 5 ]; then VULN=1; fi
    if [ "$MINOR" -lt 11 ]; then VULN=1; fi
elif [ "$MAJOR" -lt 16 ]; then
    VULN=1
fi

if [ "$VULN" -eq 1 ]; then
    echo -e "\033[0;31m[CRITICAL ALERT] GitLab instance (${GITLAB_VER}) is VULNERABLE to CVE-2024-6385!\033[0m"
    echo -e "\033[0;31m[ACTION REQUIRED] Upgrade immediately to 17.1.2+, 17.0.3+, or 16.11.5+.\033[0m"
    exit 2
else
    echo -e "\033[0;32m[OK] GitLab instance meets or exceeds patched release baseline.\033[0m"
fi

Tier 2: Migrating Protected Variables to Dynamic OIDC Federation (HashiCorp Vault)#

Static protected CI/CD variables represent an acute single point of failure. Organizations must migrate production deployments to GitLab ID Tokens (JSON Web Token OIDC Federation) integrated with HashiCorp Vault, AWS STS, or GCP Workload Identity.

When using OIDC federation, no static cloud credentials or passwords exist inside GitLab project settings. Instead, each executing job dynamically requests a short-lived token from Vault, which verifies that the token's claims (iss, sub, ref_type) strictly match authorized branches.

Secure .gitlab-ci.yml Template: HashiCorp Vault OIDC Authentication

YAML 
# Secure GitLab CI/CD Pipeline Configuration using Dynamic OIDC Secrets
stages:
  - deploy

deploy_production:
  stage: deploy
  image: hashicorp/vault:latest
  # Generate ephemeral, cryptographically signed OIDC ID Token
  id_tokens:
    VAULT_ID_TOKEN:
      aud: https://vault.corp.internal:8200
  variables:
    VAULT_ADDR: https://vault.corp.internal:8200
    VAULT_AUTH_ROLE: gitlab-production-deployer
  before_script:
    - echo "[*] Authenticating to HashiCorp Vault via GitLab OIDC JWT..."
    # Log in to Vault using the job's dynamic ID token
    - export VAULT_TOKEN=$(vault write -field=token auth/jwt/login role=$VAULT_AUTH_ROLE jwt=$VAULT_ID_TOKEN)
  script:
    - echo "[*] Retrieving short-lived AWS deployment credentials..."
    - export AWS_CREDENTIALS=$(vault kv get -format=json secret/production/aws)
    - export AWS_ACCESS_KEY_ID=$(echo "$AWS_CREDENTIALS" | jq -r .data.data.access_key)
    - export AWS_SECRET_ACCESS_KEY=$(echo "$AWS_CREDENTIALS" | jq -r .data.data.secret_key)
    # Execute deployment steps with temporary credentials (valid 15 minutes)
    - aws sts get-caller-identity
    - ./deploy_production.sh
  rules:
    # Strictly enforce that this job executes ONLY on the protected default branch
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_COMMIT_REF_PROTECTED == "true"'
  tags:
    - hardened-production-runner

Tier 3: GitLab Runner Hardening & Isolation#

GitLab Runners execute untrusted code committed by developers. If runners are poorly configured, a compromised pipeline immediately pivots into the internal network.

1. Deprecate Privileged Docker-in-Docker (DinD)

Do not run GitLab Runners in privileged mode (privileged = true). To build container images securely inside CI/CD pipelines without exposing the Docker daemon socket or running root containers, utilize rootless build tools such as Google Kaniko, Buildah, or Podman:

YAML 
# Kaniko Container Build without Privileged Mode or Docker Socket
build_container:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.23.0-debug
    entrypoint: [""]
  script:
    - /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"
  rules:
    - if: '$CI_COMMIT_TAG'

2. Runner Configuration Hardening (/etc/gitlab-runner/config.toml)

Configure the runner daemon with strict limits, non-privileged execution, and volume restrictions:

TOML 
[[runners]]
  name = "hardened-linux-runner-01"
  url = "https://gitlab.corp.internal"
  token = "glrt-xxxxxxxxxxxxxxxxxxxx"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    # STRICT SECURITY SETTINGS:
    privileged = false
    disable_entrypoint_overwrite = true
    oom_kill_disable = false
    disable_cache = false
    # Prevent mounting of host docker socket or sensitive directories:
    volumes = ["/cache"]
    network_mode = "bridge"

Tier 4: Branch Protection & Merge Request Pipeline Policies#

To prevent untrusted merge requests from triggering pipelines with privileged access, enforce project-level pipeline policies in GitLab Settings:

  1. Enable "Pipelines must succeed": Require all verification checks to pass before merging.
  2. Prevent Fork Pipelines from Accessing Secrets: Navigate to Settings > CI/CD > General pipelines and disable "Public pipelines". Under Settings > CI/CD > Variables, ensure all production variables have the "Protected" and "Masked" flags enabled, and configure "Environment Scope" strictly to production.
  3. Require Approvals on External Merge Requests: Under Settings > CI/CD > Runners, set external contributor pipelines to require explicit approval from a Maintainer before jobs execute on shared runners.

Production Detection Queries: Hunting Identity Mismatches & Variable Leaks#

Blue teams must deploy continuous detection monitoring across GitLab Rails audit logs and runner host telemetry to detect unauthorized pipeline execution delegation and secret harvesting.

Production Sigma Detection Rule: Pipeline Trigger Author Mismatch#

The following production-ready Sigma rule monitors GitLab audit events (gitlab-rails/audit_json.log) to detect instances where a pipeline is created with a pipeline_user_id differing from the committer or branch creator:

YAML 
title: Suspicious GitLab CI/CD Pipeline Execution User Delegation (CVE-2024-6385)
id: 3e7a1b9f-5c2d-4e8a-8f12-a9b0c7d3e5f2
status: production
description: |
    Detects instances where a GitLab CI/CD pipeline is created with an execution user context (pipeline_user_id)
    that differs from the author of the commit or the user invoking the pipeline API, indicative of
    CVE-2024-6385 or CVE-2024-5655 exploitation attempting to access protected CI/CD variables.
references:
    - https://about.gitlab.com/releases/2024/07/10/patch-release-gitlab-17-1-2-released/
    - https://nvd.nist.gov/vuln/detail/CVE-2024-6385
    - https://attack.mitre.org/techniques/T1548/

tags:
    - attack.initial_access
    - attack.t1190
    - attack.privilege_escalation
    - attack.t1548
    - attack.credential_access
    - attack.t1552.004
logsource:
    service: gitlab-audit
    product: gitlab
detection:
    selection_event:
        event_type: 'pipeline_created'
        pipeline_status: 'created'
    filter_bot_accounts:
        pipeline_user_username|endswith:
            - '-bot'
            - '-service'
            - 'gitlab-ci'
    condition: selection_event and not filter_bot_accounts
falsepositives:
    - Scheduled maintenance pipelines triggered automatically by project owners on repositories with external contributions.
level: high

Falco Runtime Rule: Hunting Malicious Reverse Shells on GitLab Runners#

Deploy the following Falco rule across your GitLab Runner hosts to detect job scripts spawning interactive reverse shells or querying cloud metadata endpoints:

YAML 
- rule: Suspicious Reverse Shell Spawned in GitLab Runner Container
  desc: Detects interactive shell execution with network redirection inside GitLab Runner containers
  condition: >
    container and container.image.repository contains "gitlab-runner" and
    (evt.type = execve and proc.name in (bash, sh, zsh, dash)) and
    (proc.cmdline contains "/dev/tcp/" or proc.cmdline contains "nc -e" or proc.cmdline contains "mkfifo")
  output: >
    Reverse Shell Attempt in GitLab Runner Job
    (container_id=%container.id image=%container.image.repository cmdline=%proc.cmdline
    user=%user.name parent=%proc.pname)
  priority: CRITICAL
  tags: [container, devsecops, cicd, privilege_escalation, mitre_t1059]

Enterprise Mitigation Matrix: Comparing Remediations for GitLab CI/CD#

The following matrix compares available defensive controls across security effectiveness, implementation complexity, operational risk, and enterprise trade-offs:

Defensive Approach Control Tier Primary Mechanism Implementation Complexity Performance Impact Operational Risk Overall Effectiveness
GitLab Security Release Patch Platform Application Patches Ci::CreatePipelineService identity delegation logic Low (Standard Omnibus / Helm package update) Zero (0%) Low (Requires standard service restart window) Definitive for Vuln
Migrate to OIDC ID Tokens (Vault) Secrets Management Ephemeral short-lived credentials; eliminates static variables Medium (Requires Vault / Cloud IAM federation setup) Zero (0%) Low to Medium (Requires updating .gitlab-ci.yml files) Architectural (Next-Gen)
Deprecate Privileged DinD Runners Runner Infrastructure Replaces privileged Docker execution with Kaniko / rootless OCI Medium (Updating build job images and runner configs) Low (<5% image build time difference) Low (Legacy Docker build arguments may need adjustment) High (Stops Host Escapes)
Fork Pipeline Approval Policies Governance / Policy Enforces manual maintainer approval on external merge requests Very Low (Project configuration toggle in web UI) Low (Adds human latency for external PR runs) Very Low (Protects runners from untrusted fork jobs) High (Stops Unauth PRs)
Audit Log Mismatch Monitoring Detection Telemetry Detects discrepancies between pipeline author and committer Low (SIEM / ELK ingestion of audit_json.log) Zero (0%) Zero (Read-only monitoring) High (Incident Triage)

Incident Response & Verification Playbook: Blue Team Containment & Auditing#

When a SIEM alert or audit log discrepancy reveals potential exploitation of CVE-2024-6385, execute the following incident response workflow:

Incident Response Flowchart#

flowchart TD
    classDef client fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef gate fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef secure fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef audit fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5

    Alert[SIEM Alert: Pipeline Author Mismatch / Rogue Runner Process]:::client --> Triage{Phase 1: Alert Triage & Scope Analysis}:::gate

    Triage -- Scheduled Pipeline Run by Project Owner --> ValidateBenign[Verify Pipeline Trigger Schedule & Close Ticket]:::secure
    Triage -- Unprivileged User Triggering Maintainer Pipeline --> Incident[Confirmed CVE-2024-6385 Exploitation]:::drop

    Incident --> Containment{Phase 2: Immediate Containment}:::gate
    Containment --> CancelPipeline[Cancel Active Running Pipeline via GitLab API / Web UI]:::drop
    Containment --> PauseRunner[Pause Compromised GitLab Runner to Prevent Job Processing]:::drop
    Containment --> RevokeProjectTokens[Rotate All Protected CI/CD Variables & Deployment Keys]:::drop

    Containment --> Forensics{Phase 3: Digital Forensics & Telemetry Collection}:::gate
    Forensics --> InspectGitlabLogs[Extract gitlab-rails/audit_json.log and api_json.log]:::audit
    Forensics --> AuditCIYAML[Inspect .gitlab-ci.yml Committed to Exploited Branch]:::audit
    Forensics --> CheckRunnerHost[Examine Runner Host for Dropped Binaries & Outbound Sockets]:::audit

    Forensics --> Remediation{Phase 4: Eradication & Hardening}:::gate
    Remediation --> PatchGitlab[Upgrade GitLab Instance to Version 17.1.2+ Immediately]:::secure
    Remediation --> PurgeStaticSecrets[Migrate Compromised Secrets to HashiCorp Vault OIDC]:::secure
    Remediation --> RebuildRunner[Re-image Runner Nodes from Clean Gold Master Images]:::secure

Step-by-Step Response Checklist#

Phase 1: Vulnerability Scoping & Version Auditing

  • Execute audit_gitlab_patch.sh to determine whether the GitLab instance is running an affected version (< 17.1.2, 17.0.3, or 16.11.5).
  • Query GitLab PostgreSQL or audit logs for all pipelines triggered via merge requests or external API calls over the past 30 days.
  • Cross-reference pipeline execution authors (pipeline.user_id) against the author of the triggering Git commit (commit.author_id). Flag any mismatch where an unprivileged user triggered a job executed by root or a project Maintainer.

Phase 2: Pipeline Log Forensics & User Identity Mismatch Triage

  • Inspect the raw .gitlab-ci.yml committed to the branch associated with the suspicious pipeline. Look for base64-encoded strings, external curl/wget downloaders, or reverse shell patterns (/dev/tcp/).
  • Review the execution logs of the flagged pipeline jobs to identify whether env, printenv, or exfiltration commands were executed.
  • Audit all project-level and group-level CI/CD variables configured in the repository. Identify every secret that was exposed to the job environment.

Phase 3: Credential Invalidation & Runner Sanitization

  • Immediately rotate all AWS IAM access keys, Kubernetes cluster credentials, Vault tokens, and database passwords that were stored as protected variables in the affected project.
  • Revoke and re-generate all GitLab Deploy Tokens and Deploy Keys associated with the compromised repository.
  • Terminate the active runner container and reboot the runner virtual machine. If the runner was configured with privileged = true, consider the host operating system compromised and re-image the node from a clean base image.
  • Apply the latest GitLab security release and migrate static secrets to dynamic OIDC JWT identity tokens before re-enabling runner queues.

Executive Takeaway Table: Threat Vectors, Detection Signals, and Primary Mitigations#

The following executive summary consolidates the core attack vectors, defensive telemetry signals, and recommended engineering remediations for GitLab CVE-2024-6385:

Attack Vector / Technique Primary Exploitation Mechanism Telemetry & Detection Signal Recommended Mitigation Verification Command
Pipeline User Delegation (T1548) Ci::CreatePipelineService runs unprivileged job under maintainer context GitLab audit log: pipeline_user_id does not match invoking API caller Upgrade GitLab to version 17.1.2+, 17.0.3+, or 16.11.5+ Run audit_gitlab_patch.sh
Protected Variable Theft (T1552) Delegated job accesses masked and protected production CI/CD secrets GitLab Runner: High-volume environment variable dumping or external POST Migrate from static variables to dynamic HashiCorp Vault OIDC ID Tokens Audit project CI/CD variables via GitLab API
Privileged Runner Breakout (T1059) Privileged Docker-in-Docker container accesses host Docker socket Falco / EDR: Container process mounting host filesystem or spawning shell Deprecate privileged = true; migrate to rootless Kaniko or Buildah grep -E 'privileged.*true' /etc/gitlab-runner/config.toml
Rogue Merge Request Pipelines External contributor fork triggers pipeline execution on protected runners GitLab API: Pipeline spawned from untrusted fork on protected branch Enforce "Require approval for fork merge requests" in CI/CD settings Review GitLab project CI/CD settings in web UI
Supply Chain Artifact Poisoning Stolen deploy token used to overwrite production container images Container registry: Image tag pushed outside standard release window Enforce cryptographic container image signing via Sigstore / Cosign cosign verify <image-ref> before deployment

Authoritative References & Standards#

  1. GitLab Security Release: Critical Security Release: GitLab 17.1.2, 17.0.3, and 16.11.5 — GitLab Security Advisory
  2. National Vulnerability Database (NIST): CVE-2024-6385 Detail (CVSS 9.6 Critical - CWE-284) — NIST NVD
  3. Cybersecurity and Infrastructure Security Agency (CISA): Known Exploited Vulnerabilities Catalog (KEV) - GitLab Pipeline Execution Flaws — CISA KEV Entry
  4. MITRE ATT&CK Framework: Technique T1190: Exploit Public-Facing Application & T1548: Abuse Elevation Control Mechanism — MITRE ATT&CK

Comments

Post a Comment

Drag or use arrow keys to pan • Click outside or press Esc to close