CVE-2022-3279
Description
An unhandled exception in job log parsing in GitLab CE/EE affecting all versions prior to 15.2.5, 15.3 prior to 15.3.4, and 15.4 prior to 15.4.1 allows an attacker to prevent access to job logs
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE prior to 15.2.5, 15.3.4, and 15.4.1 have an unhandled exception in job log parsing allowing attackers to deny access to CI logs.
Vulnerability
In GitLab Community Edition (CE) and Enterprise Edition (EE) versions prior to 15.2.5, 15.3 prior to 15.3.4, and 15.4 prior to 15.4.1, the job log parsing logic raises an unhandled exception when processing a CI trace that contains an out-of-bounds timestamp in a custom collapsible section marker. The code path is reachable whenever an attacker with commit access to a repository or ability to influence CI job output (e.g., via supply chain compromise) inserts a section_start or section_end tag with an extremely large timestamp value. [1]
Exploitation
An attacker must have the ability to control the printed contents of a CI job trace—either by authoring or modifying a .gitlab-ci.yml file, or through a related supply chain attack that allows injection into job output. The attacker then adds a section_start or section_end line to the job script with an abnormally large timestamp (e.g., 999999...). When GitLab attempts to parse the trace and display it in the web interface, the unchecked timestamp triggers an unhandled exception, preventing the log from loading. [1]
Impact
Successful exploitation causes a denial of service for the affected CI job log: the trace cannot be retrieved or viewed via the GitLab UI or API. This allows the attacker to hide evidence of malicious activities performed during the CI job, as the log becomes inaccessible to users. No code execution or data disclosure is possible through this vulnerability; the impact is limited to log availability. [1]
Mitigation
GitLab fixed this issue in versions 15.2.5, 15.3.4, and 15.4.1, released on 2022-10-17. Users running older versions should upgrade to one of these or a later release. No workarounds are available; enabling the fix also required a backend change to properly handle out-of-bounds timestamps. [1]
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: <15.2.5, <15.3.4, <15.4.1
- Range: <15.2.5
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing upper-bound validation on the timestamp value in CI trace section parsing causes an unhandled exception when processing an out-of-bounds duration."
Attack vector
An attacker who can control the output of a CI job trace — either by editing the `.gitlab-ci.yml` file (Developer role or above) or via a compromised dependency in the supply chain — can inject a `section_end` marker with an extremely large timestamp value (e.g., a string of hundreds of `9` digits). When GitLab's backend parses this trace to render the job log, the unbounded timestamp causes an unhandled exception in `ActiveSupport::Duration.build`, resulting in an HTTP 500 error that prevents the job log from being displayed at all [ref_id=1]. This hides the attacker's CI job activity from reviewers and auditors.
Affected code
The vulnerability is in `lib/gitlab/ci/ansi2json/line.rb`, specifically in the `set_section_duration` method. The method calls `ActiveSupport::Duration.build(duration_in_seconds.to_i)` without any upper bound check on the timestamp value extracted from CI trace section markers.
What the fix does
The proposed fix clamps the parsed `duration_in_seconds` value to a range of `0` to `1.year` before passing it to `ActiveSupport::Duration.build` [ref_id=1]. This prevents the unhandled exception caused by astronomically large timestamps. The 1-year upper bound is sufficient because CI jobs already time out after a few hours, so any legitimate duration will fall well within this range.
Preconditions
- authAttacker must have Developer role or above on the GitLab project, or must be able to inject content into the CI job trace via a compromised dependency
- inputAttacker must be able to control the output printed by a CI job (e.g., via .gitlab-ci.yml or a supply-chain compromise)
Reproduction
1. Create a `.gitlab-ci.yml` file with a `before_script` that defines a `timed()` function which echoes a `section_end` marker containing an extremely large timestamp (e.g., 999... repeated hundreds of times). 2. In the `script` section, call `timed` with various commands. 3. Wait for the job to finish. 4. Attempt to load the job output — the `trace.json` network request returns a 500 error, preventing the job trace from being displayed [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.