CVE-2025-59476

What it actually does

The flaw is an improper input validation issue in Jenkins log formatting. In Jenkins 2.527 and earlier and Jenkins LTS 2.516.2 and earlier, user-controlled content written into log messages is not normalized before being emitted to console-oriented logs such as jenkins.log. If an attacker can cause Jenkins or a plugin to log attacker-supplied text containing carriage return or line feed characters, that text can create additional apparent log lines. Those forged lines can make logs appear to contain events that did not actually occur, hide the context of real events, or mislead responders and administrators during review. The issue does not directly provide code execution, privilege escalation, or data access; its primary impact is log integrity and forensic reliability.

Why it matters to the business

The main business risk is loss of trust in Jenkins audit and operational logs. Because Jenkins commonly supports build, deployment, and automation workflows, misleading log entries can slow incident response, obscure suspicious activity, create false confidence that an action was performed by another user or system component, or cause administrators to make incorrect operational decisions. The CVSS score is moderate at 5.3, EPSS is low at 0.00335, it is not listed in CISA KEV, and there is no known public exploit maturity reported, so this should generally be treated as a routine but important hardening update rather than an emergency internet-wide exploitation event.

How an attack unfolds

An attacker first needs a way to influence content that Jenkins records in logs, such as a username, job name, build parameter, SCM metadata, HTTP request value, plugin-supplied field, or other user-controlled string that is later included in a log message. The attacker embeds carriage return and/or line feed characters followed by text that resembles a legitimate Jenkins log entry. On vulnerable versions, the formatter writes the content without marking or transforming the embedded line break, so the resulting jenkins.log or equivalent output appears to contain extra log lines. A reviewer or automated parser may then interpret those forged lines as real Jenkins events. After patching, Jenkins prefixes inserted lines with markers such as [CR]>, [LF]>, or [CRLF]>, making the manipulation visible and reducing the chance that forged lines are mistaken for authentic log records.

How to fix it

Upgrade Jenkins to a fixed release: Jenkins weekly 2.528 or later, or Jenkins LTS 2.516.3 or later. For source-based tracking, the Jenkins fix is associated with commit 6a3d39f138a1b1cc33759e5f2b34fe0c76378dab. Where Jenkins is consumed through operating system or downstream packages, apply the vendor-provided fixed package; the provided package metadata lists zabbix on Debian 11, Debian 12, and Debian 13 as fixed in 1:2.0.2+dfsg-1, but remediation should be validated against the actual package and advisory relevant to the deployed component. If immediate upgrade is not possible, reduce exposure by limiting who can submit build parameters, create or rename jobs, configure SCM values, install plugins, or otherwise provide values that are logged; restrict administrative log access to trained personnel; and treat suspicious multiline log entries as untrusted until corroborated with independent telemetry.

How to confirm the fix worked

Confirm the deployed Jenkins version is 2.528 or later for weekly releases, or 2.516.3 or later for LTS releases. Review package manager output, container image tags, Jenkins /manage/about information, and startup logs to ensure the running controller is the upgraded version, not only that a package is present on disk. As a functional validation, in a non-production test instance submit a benign value containing CR, LF, or CRLF characters through a controlled field that is known to be logged and verify that inserted lines are visibly prefixed with [CR]>, [LF]>, or [CRLF]>. Confirm log collectors, SIEM pipelines, and parsers preserve or alert on these markers rather than stripping them. Also verify that no vulnerable Jenkins controller images or rollback artifacts remain in deployment pipelines.

Typical attack path

1. Identify a Jenkins interaction point or plugin behavior that logs user-controllable input.
2. Submit crafted input containing carriage return and/or line feed characters followed by text formatted to resemble a legitimate Jenkins log entry.
3. Trigger the workflow, request, build, authentication event, or plugin action that causes Jenkins to write the supplied content to logs.
4. Rely on the vulnerable log formatter to emit the embedded line breaks as apparent separate log entries without warning markers.
5. Use the forged log output to mislead administrators, confuse incident timelines, poison downstream SIEM parsing, or obscure surrounding activity.

How to detect it

To determine whether this behavior was already abused, review Jenkins controller logs, including jenkins.log, system logs for the Jenkins service, web/proxy access logs, plugin logs, and centralized SIEM copies of Jenkins events. Focus on entries where a single action appears to produce unexpected extra lines, where log timestamps or log levels are inconsistent with surrounding records, where lines lack the normal logger prefix, or where usernames, job names, build parameters, SCM commit messages, branch names, request values, or plugin-generated fields appear split across multiple lines. On patched systems, search for [CR]>, [LF]>, and [CRLF]> markers, which indicate that Jenkins detected line breaks inserted through log message content. On vulnerable historical logs, compare Jenkins entries against independent telemetry such as reverse proxy request logs, identity provider audit events, SCM events, build queue records, and agent-side logs; forged Jenkins log lines may not have matching evidence in these sources. Be cautious with automated detections because the vulnerability enables log poisoning rather than a unique exploit payload, so absence of a fixed string does not prove absence of exploitation.

• [CR]>
• [LF]>
• [CRLF]>
• /var/log/jenkins/jenkins.log
• jenkins.log
• $JENKINS_HOME/logs

What your security team should do

• Inventory Jenkins controllers and packaged deployments and prioritize upgrading any Jenkins 2.527 or earlier, or LTS 2.516.2 or earlier, to Jenkins 2.528+ or LTS 2.516.3+.
• Treat this as a log-integrity issue: review detection rules, audit workflows, and incident-response playbooks that assume every line in jenkins.log is independently trustworthy.
• Search historical Jenkins logs for suspicious multiline entries and, on upgraded systems, for [CR]>, [LF]>, and [CRLF]> markers that may indicate attempted newline injection.
• Restrict untrusted users from controlling values commonly written to logs, including job names, build parameters, SCM metadata, and plugin configuration fields.
• Validate that centralized logging tools do not collapse, discard, or reinterpret newline markers in ways that hide injected content.
• Correlate Jenkins logs with independent sources such as reverse proxy logs, authentication provider logs, SCM audit logs, build agent logs, and operating system logs during investigations.
• Monitor vendor advisories for Jenkins core and plugins, because exploitability depends heavily on which logged fields are reachable by lower-privileged or unauthenticated users.