CVE-2024-47803

What it actually does

Jenkins versions 2.478 and earlier and LTS 2.462.2 and earlier fail to redact values submitted through the `secretTextarea` form field when an error message is generated during form submission processing. Because `secretTextarea` is intended for multi-line secrets such as private keys, certificates, API tokens, credentials, or configuration blocks, a validation or processing error can cause the raw secret value to be written into the error response and potentially into Jenkins system logs or other log aggregation destinations. The flaw is an information disclosure issue; it does not directly grant code execution or authentication bypass, but exposed secrets can enable follow-on compromise depending on what the leaked secret controls.

Why it matters to the business

The main risk is accidental leakage of sensitive CI/CD secrets into logs, where they may be accessible to administrators, support staff, log aggregation systems, backups, or attackers who have gained read access to logs. In a Jenkins environment, leaked secrets can have outsized operational impact because they may unlock source code repositories, artifact registries, deployment systems, cloud accounts, signing keys, or production credentials. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but remediation should still be prioritized because CI/CD systems often hold high-value credentials and log retention can preserve exposed secrets long after the original error occurred.

How an attack unfolds

An attacker typically needs the ability to access or influence a Jenkins form that uses the `secretTextarea` field, such as a configuration form for a core feature or plugin that accepts multi-line secrets. The attacker submits a malformed or otherwise invalid form value that causes Jenkins to generate an error message during form processing. On affected versions, Jenkins redacts some secret types but fails to redact the multi-line value from `secretTextarea`, causing the submitted secret content to appear in the generated error message and potentially in the Jenkins system log. If the attacker can view the resulting UI error, read Jenkins logs, access centralized log storage, or compromise an account with log-viewing permissions, they can recover the secret. The attacker can then use the leaked credential outside Jenkins or within Jenkins to access source repositories, cloud services, deployment targets, package registries, or other connected systems.

How to fix it

Upgrade Jenkins to a fixed release: Jenkins weekly 2.479 or later, or Jenkins LTS 2.462.3 or later. For source-based builds, ensure the Jenkins code includes commit `c91a0e9cac1832e8f638e2be91cb972393ac1e93` or a later equivalent fix. After patching, review plugins and custom form definitions that use `secretTextarea`, and update plugins where applicable because affected workflows may be exposed through plugin configuration pages. Treat any multi-line secret that may have been submitted through an affected form as potentially compromised if related errors were generated before the upgrade. Rotate exposed or potentially exposed secrets, including SSH private keys, API tokens, cloud keys, certificates, webhook secrets, deployment credentials, and repository credentials. Restrict access to Jenkins logs and centralized log stores, reduce unnecessary log retention for sensitive CI/CD systems, and avoid sending Jenkins application logs to destinations where broad groups can read them.

How to confirm the fix worked

Confirm the Jenkins version is 2.479 or later for weekly releases or 2.462.3 or later for LTS releases by checking the Jenkins About page, startup log banner, package metadata, container image tag, or `jenkins.war` version. If building from source, verify the deployed build includes commit `c91a0e9cac1832e8f638e2be91cb972393ac1e93` or a later patch. Review recent Jenkins system logs and centralized logs for form submission errors involving fields named `secretTextarea` or configuration pages that accept multi-line secrets. In a non-production test environment only, validate that submitting an intentionally invalid multi-line secret value through a representative `secretTextarea` form produces an error where the value is redacted rather than logged or displayed. Confirm that log access controls and retention policies are appropriate for CI/CD secrets.

Typical attack path

1. Identify a Jenkins instance running Jenkins 2.478 or earlier, or LTS 2.462.2 or earlier.
2. Find a Jenkins configuration page or plugin workflow that uses a `secretTextarea` field for multi-line secret input.
3. Obtain permission to submit or influence the relevant form, or wait for an authorized user or automation to submit an invalid form containing a real secret.
4. Trigger a validation or processing error during form submission.
5. Retrieve the generated error message from the web UI, Jenkins system log, support bundle, or centralized logging platform.
6. Extract the exposed multi-line secret, such as a private key, token, certificate, or credential block.
7. Use the recovered secret to access connected systems, escalate privileges, move laterally, or persist through CI/CD integrations.

How to detect it

To assess prior exploitation or accidental exposure, review Jenkins controller system logs, web request logs, support bundles, and centralized log storage covering the vulnerable period before upgrade. Focus on errors generated during configuration form submissions, especially pages or plugins that accept multi-line secrets. Search for `secretTextarea`, Jenkins/Stapler form binding exceptions, HTTP 400 or 500 responses during `/configure`, `/descriptorByName/`, `/configSubmit`, `/submit`, and plugin configuration requests, and any log entries that contain secret-like multi-line material. High-confidence exposure artifacts include private key blocks, certificate blocks, PEM headers, OAuth or API tokens, cloud access keys, kubeconfig content, SSH keys, and webhook secrets appearing near Jenkins form-processing exceptions. Also review access logs for users or IP addresses that retrieved pages or logs containing those errors, and audit log access in centralized logging platforms. Because exploitation may look like ordinary misconfiguration or validation failure, the most reliable signal is the presence of actual secret material in Jenkins-related logs rather than a unique exploit string.

• secretTextarea
• /var/log/jenkins/jenkins.log
• /var/log/jenkins/jenkins.err.log
• $JENKINS_HOME/logs/
• $JENKINS_HOME/jenkins.log
• BEGIN PRIVATE KEY
• BEGIN RSA PRIVATE KEY
• BEGIN OPENSSH PRIVATE KEY
• BEGIN EC PRIVATE KEY
• BEGIN CERTIFICATE
• END PRIVATE KEY
• END RSA PRIVATE KEY
• END OPENSSH PRIVATE KEY
• END EC PRIVATE KEY
• END CERTIFICATE
• configSubmit
• descriptorByName
• org.kohsuke.stapler
• StaplerRequest
• java.lang.IllegalArgumentException
• javax.servlet.ServletException
• hudson.model.Descriptor
• Failed to submit form
• Invalid form submission

What your security team should do

• Inventory Jenkins controllers and prioritize upgrades of any instance running Jenkins 2.478 or earlier or LTS 2.462.2 or earlier.
• Upgrade to Jenkins 2.479 or later, or LTS 2.462.3 or later, and verify the fix is present before closing remediation.
• Identify Jenkins jobs, global configurations, credentials workflows, and plugins that accept multi-line secrets through configuration forms.
• Search Jenkins controller logs, support bundles, and centralized log platforms for evidence of unredacted multi-line secrets in form submission errors.
• Rotate any secrets found in logs, and consider rotating high-value multi-line secrets entered into Jenkins during the vulnerable period if logging coverage is incomplete.
• Restrict read access to Jenkins logs and log aggregation indices that may contain CI/CD secrets.
• Review retention and backup policies for Jenkins logs because exposed secrets may persist in archived logs even after patching.
• Add monitoring for future appearances of private key headers, API token patterns, certificate blocks, and cloud credential formats in Jenkins logs.